Repository pattern has been around for long time but suffers through some issues. General nature of its implementation comes in the way of extending repository pattern to use it with complex domain models involving large number of entities. Repository contract can be limiting and confusing when there is a need to write complex and very specific queries. Trying to fix these issues with repositories may result in leaky abstraction which can bite us later. Moreover, repositories maintained with less care have a tendency to grow into god objects and maintaining them beyond that point becomes a challenge.

Specification pattern and query object pattern solve these issues on the read side of the things. Different applications have different data access requirements. Some applications are write-heavy while others are read-heavy. But there are a minute number of applications that fit into former category. A large number of applications developed these days are read-heavy. I have worked on applications that involved more than 90 percent database operations that queried data and only less than 10 percent operations that actually inserted/updated data into database. Having this knowledge about the application you are developing can be very useful in determining how you are going to design your data access layer.

For a read-heavy application, specification patterns and query object patterns are serious design patterns to consider. Specification pattern provides a highly reusable way of writing filter criteria. Queries written using specification pattern are not only highly reusable but are also highly testable. Lately, testability is becoming a more and more important characteristic to have for any software component. The only limitation of specification pattern is that it can only be used with lambda expressions. Query object pattern on the other hand can be used with both LINQ syntax and lambda expressions. Query object pattern goes beyond just filter criteria and encapsulates the whole query into an object which is reusable and testable like specification pattern. Because query pattern encapsulates the whole query, the extent to which it can be reused may not match that of specification pattern but I personally prefer it for the fact that it does not leak any aspect of query outside its object boundary.

That brings us to the end of our NHibernate journey. Not quite, but yes, in a way. We do not have any further chapter which builds upon concepts we learned in this chapter and introduces concepts that are logically next in order of learning. In the next chapter specifically, we would handle the interesting topic of working with legacy databases. Legacy databases can come in different shapes and forms. Legacy databases is more of a situation where there is lack of harmony between database schema and domain model. So in most aspects, legacy databases would give us trouble when we try to interact with them using NHibernate or tools such as NHibernate. While there are features in NHibernate that help in some of these situations, there also are some tricks and tips that might save you some time and energy. If you are working on such a database, then next chapter is for you.