I would welcome any comments and/or suggestions from those using this project.

In my current project I have two domain entities ‘Inventory’ and ‘Item’. An inventory aggregates items. Now lets assume the highly likely user story of a user performing a search of the inventory to retrieve ‘n’ matching items. What seems like a nice encapsulated approach, in keeping with the key OO tenet of correct assignment of responsibilities, is to have a method Search() on the Inventory Class. The problem is that this approach requires you to call into the persistence subsystem, let’s call it a relational database as a few companies seem to use those, in order to hydrate the necessary items and that means polluting your model with data access concerns.

In the service layer architecture Inventory is not required as the DAL is called upon, sometimes even directly with a call, for example, to the NHibernate API, to serve up the necessary Item instances which can then be DTO’d and sent on their way. The Inventory class is now a little more anemic having lost this responsiblity and the search effectively lives outside of the model.

Separation of concerns is a wonderful thing with obvious benefits so please don’t think for a minute that I am questioning its architectural merit, I am just tossing this thought out there for comments or someone to tell me that what I should be doing is ‘X’ or that I am just persistence ignorant.

Looking to buy a house in Sevenoaks?

Engine engine = new Engine(Country.UK);
ActionConstraints searchConstraints = new ActionConstraints("Sevenoaks", ListingType.Buy);
Result result = engine.Search(searchConstraints);

Don’t like gardening but love your car?

Engine engine = new Engine(Country.UK);
ActionConstraints searchConstraints = new ActionConstraints("Sevenoaks", ListingType.Buy);
searchConstraints.AddIncludeKeyword("garage");
searchConstraints.AddExcludeKeyword("garden");
Result result = engine.Search(searchConstraints);

LINQ to Nestoria

var listings = (from listing in engine.Search(searchConstraints).Response.Listings
                where listing.BedroomCount > 3
                orderby listing.BedroomCount
                select listing);

While the framework is currently targeted squarely at ASP.Net development, I feel that its benefits could extend beyond that so have been in touch with Billy and offered to create a WCF based solution that leverages S#arp. I now have a working demo that uses Northwind (of course) and hope that this can benefit others.