First I'll get to the point, then I'll elaborate.  When designing something for broad consumption, start with an example of a simple implementation and work backwards.  Imploy a test-driven-development approach to your interface and you might avoid several mistaken paths...

And to give credit to the source of the advice:

CHRIS ANDERSON Each developer has his or her own methodology,

and although there isn’t anything fundamentally wrong with using other

modeling approaches, the problem generally is the output. Starting by writing

the code you want a developer to write is almost always the best

approach—think of it as a form of test-driven development. You write the

perfect code, then work backwards to figure out the object model that you

would want.

 ...and now more fluff!  Mostly, this is stream of consciousness but perhaps someone will have something to say or may just find inspiration!

For those who aren't privy, I am now a fulltime employee of HPCi.  The reason for hanging up the independent hat and accepting the shackles of fulltime employment is that we mutually want to allow me to have more responsiblity and involvement in higher level deceisions and direction.  Basically, I am incresing my architecture role within the company. 

That being said, my involvement in code should migrate upwards such that many of my deliverables are used across the organization.  Sometimes my deliverables are nothing more than design and sometimes, merely suggestions. 

One complexity I am trying to resolve is a continous dependency built into our products on the underlying search technology used.  This goes beyond a traditional Oracle vs. SQL Server agility and the abstraction of data interaction from the business logic and presentation tier.  We use a web-based search product that handles all the details of denormalization in a consistent manner.  It is great at some things, really great.  At other things, like relational data, not so good.  The websites that use this product call directly to the tool's library API to execute searches.  The result of which is woven all the way up to the presentation code so that changing the search mechanism would require extensive modification across all tiers.  What tiers?  exactly!  More importantly, to accomplish otherwise simple things, we often have to write complex logic against the data to shoe-horn in functionality that isn't natively supported.  To further muddy the waters, controls that live on a page are loaded dynmically in an IBuySpy portal sort of way so they are not aware of each other and the page is completely divorced from any specific functionality such as searching.  There are many other reasons why I want to create a proxy class that can handle all this complexity and provide a simple, consistent interface for searches.  My goal is that the synchronization of multiple searches, plus the complexity of search manipulation, could be encapsulated in addition to allow the searching engine and its datastore to be swapped out where the class that consumes the search would not need to change (unless it relied on the internals of the search product, which I also want to expose).

My first iteration preceded reading the blog-post-subject-suggestion (write client pice first).  I started a two way eventing model that would broadcast a search intention, via an existing page event model, passing a delegate to a synchonization method, which would then wire the control to a search execution control.  The search execution control would send its search exectution intention through the same eventing system and the controls interested in .  The result is that all controls would then be wired to either execute a search or receive a search.  It worked but it was a mess.  It was immensely complicated and not easy to communicate or document.  scratch that one...

I went through several modifications before I finally realized that developers create objects and execute methods and asking them to do much else is instructing them, "please don't use this, its too complicated."  All this eventing and delegate nonesense needs to taken off the developers' plate.  I implemented a singleton search executor and a search manager class that orchestrates the execution and synchronization of the search.  When I was finished, it was much simpler but I was still passing back the very propriatary search results class to the client.  It was still impossible to get the search from another datastore and pass it back through this framework.  

That's when I read this short tip and the light bulb lit like the warm glow of a 12AX7 on an old Fendar Twin. 

I deleted all the code in the display control that passes the selected criteria to the search manager with the ideal world.  It immediately identified that I not only needed a search result object that was not directly tied to a search tool or data store but I needed a criteria object that could be sub classed for each implementation. 

Since the selection of criteria values and the search itself cannot easily be seperated, it is unrealistic to think I could create a completely generic search object hierarchy without completely rewriting the entire website.  However, it is realistic to think I might create a WebsiteCriteria class that internally creates a search specific criteria class and passes the details to the search tool.  Then the search result can be wrapped in a generic search result container.  At this time, the front end requires some of the details of the proprietary search as the listings that are returned are all dependent on the search tool that generate the results.  Therefore, I expose the underlying deatils for those that need them.  Eventually, I'd like to move more and more into the abstraction layer so tat a listing is a listing no matter where it came from.  I think I'm on the right track.  Regardless, the code to use this new structure is incredibly simple.  Create a search manager object.  If you care about synchronizing with other searches, pass a synchronization delegate to the constructor.  Call the execute method, passing a criteria object as your selections.  You will get a search result back.  Any onther class interested in synchronizing will be notified by the single search executor.  Its getting there.  Its much better then every control executing the same search and depending on page events and session for search details.  Baby steps.