http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660The internal impl. of the query objects, maybe. http://ayende.com/3955/repository-is-the-new-singleton#comment76http://ayende.com/3955/repository-is-the-new-singleton#comment76Tue, 09 Jun 2009 17:17:16 GMTWhat is the place for LINQ in this scheme in your opinion? http://ayende.com/3955/repository-is-the-new-singleton#comment75http://ayende.com/3955/repository-is-the-new-singleton#comment75Tue, 09 Jun 2009 17:10:56 GMTQuery objects are nice even if you have dao wtih Query(queryspec, pageinfo, sortinfo). I've usually compiled "repositories" that are actually DAO-s but they tend to grow longer than any class should be and have exactly the same signature issues you describe. Putting them out of data layer can sometimes introduce weird things - compiling query might be rather infested with knowledge of data model. Or is it just my models... http://ayende.com/3955/repository-is-the-new-singleton#comment74http://ayende.com/3955/repository-is-the-new-singleton#comment74Wed, 20 May 2009 23:48:26 GMTAt first glance, and on [very] simple projects, the Repository Pattern (per PoEAA) can appear to be an unnecessary layer of abstraction and overhead. However, I have yet to work on an application where all of the data we require to create the domain objects resides in a single database. Especially when any accounting information/human-resource data is ever needed to match up against other Domain objects. The Repository Pattern allows the domain and data-services layers to be completely isolated by abstracting out any dependencies between the myriad data-access components that might be required per domain object. This abstraction also allows us to implement more stable solutions where the data is being supplied today by a database, but tomorrow can be easily swapped out by web-services from another party or in the cloud. http://ayende.com/3955/repository-is-the-new-singleton#comment73http://ayende.com/3955/repository-is-the-new-singleton#comment73Mon, 27 Apr 2009 20:33:12 GMTI keep seeing a lot of talk in this arena regarding what is in reality free form queries for reporting purposes and nothing to do with any domain behavior. Not always but usually, IMHO, this is a seperate part of the domain (read: new objects). Make reporting concepts a first class citizen instead. I've also noticed that for some reason I cannot understand that people somehow think that a specification, a query object, and a repository interface are all mutally exclusive. A repository is there to make domain query concepts explicit. This does not however that an intention based concept cannot be modeled in your application. This is where we've done lots of work with expression trees to expression the "what i want" not the "how to do it". [shrugs] http://ayende.com/3955/repository-is-the-new-singleton#comment72http://ayende.com/3955/repository-is-the-new-singleton#comment72Fri, 24 Apr 2009 18:25:47 GMTHello Ayende @ Rahien I totally understand your opinion, I've myself experienced similar peculiarities. I did start a project with the ohh so well know Repository-pattern using Linq to SQL, and as this wasn't enough I quickly jumped into the oh-so-great Generic Repository! (you posted a similar opinion earlier also *S* ) What a shame and waste of time, luckily I created a well-functioning prototype before showing my work to the team. (well. I did actually release a small sample to them) However I dumped the generic approach into the drain. So now I ended up with those stupid methods as you pointed out. What was that? And why should I create such a method for each query - gee - don't waste my time with such old-style *LOL* Well... as time is now, we still use the Repository-pattern, but I've modified it. There's only one method for retrieving data.: IQueryable <someobject GetData() and certainly no generic junk, why not? Because I need an easy control for deleting, updating and inserting - those methods exists inside the appropriate repositories. For instance for inserting child records I use the parent object -> Repository and inside this, because of the fact that the parent knows the childs, the parent also controls the data integrity. Inside the Repository layer I also create the neccessary specifications as extension methods, so we can use them from the Service Layer. One very important thing here, is to know that the specification really are very specific and not just a normal query. The more general queries we just create in the service layer and then just hook a specification in the end for some specific query-needs, of cause some of the extensions are overloaded. As mentioned I understand your post, but I would be a bit frustrated if we just should create all our updating, inserts from the ServiceLayer, that would mean that the service layer should have knowledge of the database which I don't like. The big question here... Would the world be a better place when we find another name for the Repository or are we going to respect the old guys with their DDD and their patent-taking of cool-sounding names ;-) >http://ayende.com/3955/repository-is-the-new-singleton#comment71http://ayende.com/3955/repository-is-the-new-singleton#comment71Thu, 23 Apr 2009 20:24:13 GMTGreg Young just did a post on CodeBetter in response to this post: [codebetter.com/.../...ad-long-live-repository.aspx](http://codebetter.com/blogs/gregyoung/archive/2009/04/23/repository-is-dead-long-live-repository.aspx) I'd like to hear your rebuttal. :) http://ayende.com/3955/repository-is-the-new-singleton#comment70http://ayende.com/3955/repository-is-the-new-singleton#comment70Thu, 23 Apr 2009 15:55:44 GMTGeorge, YAGNI http://ayende.com/3955/repository-is-the-new-singleton#comment69http://ayende.com/3955/repository-is-the-new-singleton#comment69Wed, 22 Apr 2009 06:21:04 GMTAyende, I agree that when you know ahead of time that NHibernate will be handling everything then you might as well use a single data access object such as ISession. When working with object databases you do roughly the same thing (at least with db4o you do). However, If you admit this then the whole argument of "repositories are a passing fad" goes out the window. Most projects cannot (often for lack of confidence in their technical abilities but for many other reasons too) commit to ORM-for-everything. This is something that might change as ORMs evolve and acquire data providers to cover any reasonable scenario and people get more comfortable with their use but, for the foreseeable future, repositories are still the best solution to the problem. http://ayende.com/3955/repository-is-the-new-singleton#comment68http://ayende.com/3955/repository-is-the-new-singleton#comment68Tue, 21 Apr 2009 18:19:05 GMTI should have also added, for the complex sorting, paging, max rows, criteria, etc. I use a criteria method that is similar to your query object. crit.CustomerType = CustomerType.Business; crit.MaxRows = 25; crit.PageIndex = 1; crit.SortOrder = new[] { "Lastname asc", "firstname desc"} repository.FindCustomer(crit) http://ayende.com/3955/repository-is-the-new-singleton#comment67http://ayende.com/3955/repository-is-the-new-singleton#comment67Tue, 21 Apr 2009 14:29:55 GMTI like the repository pattern, but I don't see anything wrong with your query object either. You're solving the same problem in a different way. I do have the repositories set things like paging--maybe they get the max number of rows from a configuration object and get passed the current page their on by the UI layer. I also put the session building stuff in a base class all my repositories use. Toe-may-toe, tuh-mah-toe http://ayende.com/3955/repository-is-the-new-singleton#comment66http://ayende.com/3955/repository-is-the-new-singleton#comment66Tue, 21 Apr 2009 14:24:00 GMTGeorge, I think that you can probably find a way to make NHibernate deal with that. Worst case scenario, you can tell NHibernate to save using a stored procedure. Also, note that I kept qualifying what I said with "when using NHibernate", when using other data access methods that are not as sophisticated, other rules apply http://ayende.com/3955/repository-is-the-new-singleton#comment65http://ayende.com/3955/repository-is-the-new-singleton#comment65Tue, 21 Apr 2009 07:41:05 GMTKrzysztof , I don't try to draw a line http://ayende.com/3955/repository-is-the-new-singleton#comment64http://ayende.com/3955/repository-is-the-new-singleton#comment64Tue, 21 Apr 2009 07:37:08 GMTSteve, That is how it is usually described http://ayende.com/3955/repository-is-the-new-singleton#comment63http://ayende.com/3955/repository-is-the-new-singleton#comment63Tue, 21 Apr 2009 07:36:19 GMTAndre, 1) see my other post about mocking, I don't tend to use it too much 2) I probably wouldn't want to abstract that, mind you. I want to be aware of my data access pattern, not hide it. http://ayende.com/3955/repository-is-the-new-singleton#comment62http://ayende.com/3955/repository-is-the-new-singleton#comment62Tue, 21 Apr 2009 07:35:55 GMTShould have been "RawSqlCustomerRepository to WebServiceCustomerRepository".... http://ayende.com/3955/repository-is-the-new-singleton#comment61http://ayende.com/3955/repository-is-the-new-singleton#comment61Mon, 20 Apr 2009 23:12:07 GMTAnother issue with the Repositories, when used as DAOs (the distinction is often hard to make) is that abstracting them into interfaces (such as IRepository <t) can introduce a dependency misrepresentation. There may be an ICustomerRepository and an IOrderRepository, and their abstract nature is useful for the application and its development/testing. However, they're often not as interchangeable as they seem to be, since Customers coming from an NHibernateCustomerRepository will only handle Orders coming from itself or an NHibernateOrderRepository. Having repositories only for aggregate roots is a good solution, but it isn't always possible. Of course this is more of a general trade-off with abstractions, but abstract repositories are often "marketed" with the "lets you seamlessly switch from a RawSqlCustomerRepository to RawSqlCustomerRepository" argument, and in reality it's just not true. The "query object pattern" is really good, but it's not exactly new. I've used it for a long time to be able to save user defined queries and it's also extensively used in the CMS I work with (EPiServer), where the implementation is exactly like Ayende's, except that the GetQuery method returns a HQL (yes, NHibernate) query instead of an ICriteria. >http://ayende.com/3955/repository-is-the-new-singleton#comment60http://ayende.com/3955/repository-is-the-new-singleton#comment60Mon, 20 Apr 2009 23:10:08 GMTFrom what I understand, part of your argument revolves on the contention that its silly to treat all Customers as an in memory collection and all Products as a separate one when you can just treat all objects as being in memory - something that ISession already does. Here's my problem though: I eschew the use of a repository for straight up ISession and ICriterion but then discover that in the legacy database I'm working with persisting my Customer object is either impossible with NHibernate or difficult to the point of I'm-not-going-to-have-the-time-to-learn. Or perhaps it needs to be persisted via web-service rather than the db. If I'm using the repository pattern I can inject the RawSqlCustomerRepository or WebServiceCustomerRepository implementations instead of NHibernateCustomerRepository. I know only very basic NH so there could easily be something that I'm missing but in your solution would it have to be a custom ISession full of switch statements and NotImplementedExceptions? What if we're talking about using an ORM other than NHibernate? How hard is it then? I have found the repository pattern encourages ORM use on a practical level when non-gurus are involved. For example my current project with an inexperienced team I can say "let's try to do it with NHibernate, if that turns out to be too difficult, we'll just implement the repository with something that you're familiar with like Ado.NET or stored procedures". Much easier to get buy-in, and far easier to convince them not to worry about data access, as you say "There is no database". That being said, I DO find myself suspicious of how repository seems to have taken over the world... http://ayende.com/3955/repository-is-the-new-singleton#comment59http://ayende.com/3955/repository-is-the-new-singleton#comment59Mon, 20 Apr 2009 16:32:20 GMTof course read 'weak relations' instead of 'week relations' in the previous comment... http://ayende.com/3955/repository-is-the-new-singleton#comment58http://ayende.com/3955/repository-is-the-new-singleton#comment58Mon, 20 Apr 2009 15:00:45 GMTI see, Lazy loading striking again in the domain. I'm not using NH in my current project and I indicate clearly week relations between entities. This way, repositories always Load objects, but entities can have lazy references on other objects. See [thinkbeforecoding.com/.../Lazy-load-and-persist...](http://thinkbeforecoding.com/post/2009/02/07/Lazy-load-and-persistence-ignorance) and [thinkbeforecoding.com/.../Lazy-loads-and-persis...](http://thinkbeforecoding.com/post/2009/02/08/Lazy-loads-and-persistence-ignorance-Part-2) http://ayende.com/3955/repository-is-the-new-singleton#comment57http://ayende.com/3955/repository-is-the-new-singleton#comment57Mon, 20 Apr 2009 14:58:03 GMTI have a full post on it that would air in the 30th. Or, go and read the docs about ISession.Get vs ISession.Load http://ayende.com/3955/repository-is-the-new-singleton#comment56http://ayende.com/3955/repository-is-the-new-singleton#comment56Mon, 20 Apr 2009 14:50:17 GMTWhat do you mean by 'distinction between Get & Load' ? http://ayende.com/3955/repository-is-the-new-singleton#comment55http://ayende.com/3955/repository-is-the-new-singleton#comment55Mon, 20 Apr 2009 14:47:23 GMTJeremie, That ignore the distinction between Get & Load, though http://ayende.com/3955/repository-is-the-new-singleton#comment54http://ayende.com/3955/repository-is-the-new-singleton#comment54Mon, 20 Apr 2009 14:40:31 GMTIf some of you are disturbed by the GetCustomerById methods, just remember you're using C# and that you can do things like : interface ICustomerRepository : IEnumerable <customer { Customer this[int id]; Customer this[string reference]; } then you can write things like : ICustomerRepository customers = ...; Customer customer = customers[42]; Customer otherCustomer = customer["C3P0"]; But this should be only used for domain purpose, not for querying (see remarks above...) >http://ayende.com/3955/repository-is-the-new-singleton#comment53http://ayende.com/3955/repository-is-the-new-singleton#comment53Mon, 20 Apr 2009 14:25:21 GMTI'm totally with Peter Morris regarding the ease of mocking the good old repository. m.Expect(x => x.GetByEmailAddress("me@home.com")).Return(user); Specification, or Query object, or Pipe/Filter queryable make it much harder to mock out querying mechanism. The prime culprit is "new" keyword (or extension method or other static method alternatives). http://ayende.com/3955/repository-is-the-new-singleton#comment52http://ayende.com/3955/repository-is-the-new-singleton#comment52Mon, 20 Apr 2009 04:07:44 GMTRemco, I _don't_ try to stop that. I think that it is a good thing that it does. It let me use the most of what NH can offer me. http://ayende.com/3955/repository-is-the-new-singleton#comment51http://ayende.com/3955/repository-is-the-new-singleton#comment51Sun, 19 Apr 2009 15:03:01 GMT@Ayende As Fabio and Krzysztof state, how do you prevent NHibernate (or other data access code) to leak up the layers. It should be possible to let a DI container manage the queries (like repositories), but that doesn't feel right to me. http://ayende.com/3955/repository-is-the-new-singleton#comment50http://ayende.com/3955/repository-is-the-new-singleton#comment50Sun, 19 Apr 2009 14:56:09 GMTRafal, I most certainly remember this. I was a big fan of the Repository, I think that I mention this in the post as well. That is why I feel confidant to criticize it. http://ayende.com/3955/repository-is-the-new-singleton#comment49http://ayende.com/3955/repository-is-the-new-singleton#comment49Sat, 18 Apr 2009 13:20:22 GMT"We wanted to parameterize everything and write O(1) methods for n classes." I should clarify that O(1) is the number of methods, not how long they take to run. A more typical repository-based DAL has O(n*m) methods where n is the number of classes and m is the number of specialized queries you want to do with those classes, which is usually related to the number of properties of a given class. http://ayende.com/3955/repository-is-the-new-singleton#comment48http://ayende.com/3955/repository-is-the-new-singleton#comment48Sat, 18 Apr 2009 13:16:07 GMT IRepository <orderrepository = new ValidatingOrderRepository( new SecurityRepository <order( new LoggingRepository <order( new CachingRepository <order( new NHibernateRepository <order())))); Ayende, do you remember that code? It's from your MSDN article. No wonder you got fed up with repository pattern :) >http://ayende.com/3955/repository-is-the-new-singleton#comment47http://ayende.com/3955/repository-is-the-new-singleton#comment47Sat, 18 Apr 2009 13:12:27 GMT