does this code run with Linq to NHibernate or some other Linq provider?

I’ve tried to get it work with both NHibernate and EF. Both exited with similar exceptions ala “unknown expression” or “expression type not supported”.

P.S: Don’t get me wrong I’m totally on your side when it comes to testing with in memory repositories (which by the way works exellent with that approach). I just wanted to see it in a action on a db . . . .

However, we don’t use the specification/et al patterns in our repositories. They’re specific methods for specific requests, which are mapped to data adapters internally.

Our reasoning is thus: If I want all the active users from a user repository, I don’t care how the database is setup, so I don’t care that the underlying query could contain “business” logic in the where clause. All I care about is that the data adapter is returning to me active user objects.

This allows the DB schema to change dramatically and only affects the SQL queries in the DataAccess layer. Not the repository in the business layer.

Hopefully that makes sense.

When testing the repositories, we just mock the adapters. When testing the adapters, we are hitting the DB directly, but that’s ok as they’re integration tests, not regularly run unit tests.

Absolutely right about the naming. I should’ve used Specification instead.

@Akash

I’ve seen that before. That article helped me finally break through my first barrier of groking Linq. I had forgotten about it until just now. Thanks for reminding me and for dropping a good link for the viewers here.

@Chris Martin

Yes, I’m betting that pretty much all providers will be Linq2X based from now on (Linq2Sql, Linq2NHibernate, Linq2LLBLGen, Linq2EntityFramework, etc).

As far as converting an expression tree to SQL, that’s what Linq2SQL is all about.

But, back to your point, you’re correct: this would not be an appropriate solution for old-fashioned unadulterated ADO.NET usage.

I’m not sure how I could convert an ExpressionTree to SQL.

ISpecification is perfectly testable without a DB though, and usiing an ISpecification doesn’t require a repository. That’s why on my interface I have just IsSatisfiedBy(T object).

I think our two approaches are very similar just different naming between specification and query.
In terms of just naming, I think query is more suggestive that there is a database than specification. Dunno if that is good or bad though

Dang, that Ian Cooper! I knew I had seen something like this before but my googling game up empty. Spot on.

I know my FI sucks, I was trying to make a simple point and everyone is beating me up over it, lol. Ian’s approach is very similar, but more modular.

One point about all this is that the specification is not inherently dependent upon the repository and can be tested in isolation. There’s also a distinct possibiliy of externalizing the specifications as a DSL that might be easier to tweek outside of the main application code. This is potentially a slippery slope, though, and subject to abuse. But if you keep a tight ship and require that all changes to the spec DSL have corresponding tests and don’t get rolled out to production without having been tested, it’s just as good as having it internal to the app quality-wise, but much easier for the stakeholders to see and visualize when reading the requirements-represented-as-code.

@Chris

Because the queries are inherently business logic. The statement that a “Top Customer” is one that has sales over a certain amount and is ‘preferred’ is business logic. I turn the question back around on you: Why do I need a DB to test my business logic? Or better yet, Why does my business logic require a repository?

If the object is more akin to a finder and has some sophisticated query generation logic then I would do something like this:

var userRepository = new UserRespository(new InMemoryRepository())

or

var expectedCriteria = DetachedCriteria.For
//… build the criteria I expect

Assert.Equal(expectedCriteria.ToString(), new ComplexSpecification().CreateCriteria().ToString());

Anyway in my view the Specification pattern is the best solution so I’ve been trying to use the Linq Specification approach that Ian Cooper blogged about:

http://iancooper.spaces.live.com/blog/cns!844BD2811F9ABE9C!451.entry

Not that different than your approach but although the idea is sound it doesn’t currently work that well with Linq To NHibernate.

Also I’m not sure the fluent interface here is working for me, perhaps more specifications that you combine? Dunno.

@Chad
On testing, there was some discussion on the DDD newsgroup about this ages ago.

I’ve tended to run the tests against the database but ultimately you could have specific repositories with methods that have a nice interface that just wrap the creation and execution of the specifications (Evans/Fowler both talk about this).