http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Ross, The idea in this statement is to point out differences in the implementation of the abstraction, to show that they aren't the same.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment63http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment63Fri, 03 Feb 2012 17:53:11 GMT"the EF POCO version will do an immediate delete. The NHibernate version will wait for the transaction to be committed." Maybe it's just how it's worded, but that's not a very fair argument for EF vs NHibernate. Removing the ActivateContext.SaveChanges() call will result in an identical setup to your NHibernate code, and adding a Session.Flush() call will result in an identical setup to the EF code.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment62http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment62Fri, 03 Feb 2012 01:09:37 GMT@Scott: Doing the way back machine thing here (away due to death in the family) but I really feel your comment needs a reply. You state: >Final thought: I disagree. If the business rules are solely determined by the state of the data, as is such in my example, then IMO it fits the repository definition. Sorry but demonstrably not. The Repository Pattern has a very straight forward and distinct definition about being a collection like facade over a data source. PERIOD. I am not saying what you are doing is wrong (actually from what little you state it sounds like a very logical organizational form). I am just stating that's categorically NOT a Repository. Or as my zayde would say, "Putting a feather up your butt does not make you a chicken". =) Now when we decide to group query operations together like this it is often CALLED a repository in the type name but that's more about cluing in people reading the code base as the tern <SomeEnityName>Repository has almost become synonymous with DAL Facade.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment61http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment61Fri, 20 Jan 2012 18:55:37 GMTRiccardo, Go ahead, you don't need my permission. You can fork the code and just do that.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment60http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment60Fri, 20 Jan 2012 13:01:50 GMTAyende, I'd like to make a review. I've just downloaded your source and after a quick look, time permit, I'd like to create a branch with good repositories in order to allay some of the problems that your version contains and a clean separation between your typed sql query orm and the UI. I have my already well done implementation of repositories but I'll try to use the implementation from the NSK project just for point out that the problem is not a percentage discount but how you can optimize the percentage discont without using a tight coupled app with many code repetitions. For example, how you can justify two quite identical methods AddPost, one in a controller action and one in the IMetaWeblog repository with a quite identical implementation but slightly different? http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment59http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment59Thu, 19 Jan 2012 11:41:02 GMTRiccardo, There is already a separation of concerns in the app. The views handle the UI, the controller actions either handle the BL or provide data to the view, that is it. Feel free to do a review of RaccoonBlog, I look forward to reading it.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment58http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment58Thu, 19 Jan 2012 10:37:24 GMTAyende, you can say "It is NOT a repository" also with capital letter but this doesn't change the evidence. This is not a repository... it's an ORRIBLE one repository :) A part from that, you are suggesting a way that in a real world application could produce (not for every project but I can see a big risk for medium large project) unmanageable controller actions, many static classes filled with procedural extension methods and all this stuff mixed with "external endpoint" that behave as ugly hybrid repositories. To be honest, the quick look that I have had on your controller actions was like a back in the past with a mixture and a repetitions of data access logic attached to the UI. Nothing personal but maybe it's time that someone start to analyze with a critic approach the architecture that you are suggesting and the risks that are related.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment57http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment57Thu, 19 Jan 2012 10:09:02 GMTRiccardo, This blog was written with no repository layer, because I don't believe I need it. We have been running on it for a while, including making plenty of changes along the way, with very few problems. IMetaWeblog is an ugly interface, I'll be the first to admit. This is an externally defined interface that is used to interact with Windows Live Writer, so the interface def is outside our control. It is NOT a repository, it is an external endpoint to the system, just like the controllers are.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment56http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment56Wed, 18 Jan 2012 18:15:06 GMTInteresting. I started to have a quick look on it. The first impression is that all my doubts about the opportunity to fill the UI layer (like mvc is) with queries are confirmed and this project sounds like an old fashioned ado.net+ui approach with some automapping features. Plus, there is an "interesting" IMetaWeblog that more than a service api it sounds to play the role of a repository :) with the drawback that if the project grow, this repository will explodehttp://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment55http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment55Wed, 18 Jan 2012 15:49:14 GMTThis blog is written without a repository. It uses the RavenDB session directly. https://github.com/ayende/RaccoonBlog As to your experience with using an OR/M directly causing pain, I've actually run in to the exact opposite issue. The times that I've used a repository, I've regretted it later on. It made some things easy that I never actually had to use (i.e., swapping OR/Ms) and made optimizing difficult. For instance, it hid SELECT N+1 issues on a regular basis. As for wanting to be "on the door where they have to pass to obtain data," this sounds very much like your trying to make sure other devs don't do something stupid. Unfortunately, the only way to stop someone from running with scissors is to not allow them to use the scissors. Try cutting paper like that.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment54http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment54Wed, 18 Jan 2012 15:21:48 GMT@Harry (I've just posted a reply to a similar question in the other thread) Before answer your question, I'd like to see an example of a real world application withou repository. Could you suggest me one existing example? Anyway, when I used in a medium/large app an ORM directly, I initially appreciate this approach and after a while I hate myself for this decision. I didn't use extension methods because they didn't appear to me easy to mantain and doesn't offer all benefits of a well written repository. Another point of view.... If I'm alone and I start to write down my peronal website and I have the complete control of the whole stack of layers then I can use one of the orm like EF (code first) directly and without worry about repository. If I start a new project with complex requirements, different teams for the differents layers and tiers, I can't allow developers to use freely ISession in their code because I want be always on the door where they have to pass to obtain data.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment53http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment53Wed, 18 Jan 2012 14:41:13 GMT@Riccardo, Can you explain what you can do with the `IRepository` that you cannot do with `ISession`? If you actually needed to reuse a query for a customer in its entirety *exactly as is*, then you could encapsulate the whole Linq query as an extension method off of `ISession`. Now my call would look like `session.GetCustomerWithSomeImportantAttributes();` instead of `repository.GetCustomerWithSomeImportantAttributes();`. Reuse of queries like this is pretty rare, though. Most of the time, you want the queries to have slightly different filtering, eager loading, pagination, or sorting. Each view (yes even the same view on different platforms) has different requirements for being displayed. Doing this through a repository either gives you an explosion of one-use-only methods, or parameter-hell on a god method.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment52http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment52Wed, 18 Jan 2012 14:30:05 GMT@Remi we can't reduce the interaction with data only as a query problem. When you ask for a customer your app could need specific requirements. Would you like to use an extension method for that? I think that an approach with extension methods add more problems. Where would you like to compose the query with your DAL component (session or dbcontext)? inside an mvc controller action? really? And when you need the same data for something else? are you going to copy the orrendous eager loaded query or whatever you use? I can't believe that. I like to expose an interface/repository to the consumers of data, like UI or services and control and set behind a repository a generic group of capabilities and/or set specific requirements. The approach to interact directly with a model without mediating with a repository sounds like the orrible spaghetti code that many years ago some people (me too for small apps, I have to admit) used to write. ORM are like a pill of logic but inside this pill there is a plain simple data interaction and I want limit and control in what way consumer use it.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment51http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment51Wed, 18 Jan 2012 11:39:28 GMT@Riccardo that's the eternal debate. What Ayende is saying is that many time this layer is useless because you won't reuse every piece of query. If there is some part of query that you'll reuse then create extension method for your IEnumerable<ModelClass>. And linq/EF is different than sql because it handles the mapping and the query construction, when you're directly dealing with sql you have to do a layer for abstracting this.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment50http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment50Wed, 18 Jan 2012 09:53:52 GMTI think that a generic IRepository<T> associated to a ISpecificRepository is a good base for creating repositories quickly with transactional support, without complexity and we can use them to decouple the UI from the O/RM. An O/Rm is like a Data Access Layer and there are not more differences between an sql select and a linq query on a context. If you use a context (EF or NH) directly in your UI logic (MVC or something else) you are coupling the UI with something similar at an sql query. Everywhere you need to obtain the same data you have to repeat your query (linq or sql does'n matter). Use directly an ORM inside the UI logic sounds quite easy but in a medium life of a real world application can be an issue. For example, how can you swap UI or add a service layer and reuse easily the same group of queries?http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment49http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment49Tue, 17 Jan 2012 14:07:07 GMT@bourgarel That is why you encapsulate anything more complicated than a `ISession.Get` or `ISession.Load` in an extension method. And if you group your extension methods in a logical way (perhaps by the entity they work with, orthe controller they are used by, or something else entirely depending on your project) then you can include only those extension methods you need. This will avoid the clutter on `ISession` that others are talking about. Your queries are testable and DRY, but you don't lose all the power of your OR/M to a needless abstraction.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment48http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment48Fri, 13 Jan 2012 18:20:57 GMTAyende, You're a big supporter of the "I directly use my ORM in my controller because IT IS the Repository" but in this case it's not a repository is just a Facade. When an external component (the ORM in this case) is really important in your code (like an ORM is), you HAVE TO build a facade around it. If tomorrow there is a breaking change in NH or EF, I don't want to browse my whole code to see if I was using a broken feature, or worse : avoid updating and keep working with a 5 years old version.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment47http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment47Fri, 13 Jan 2012 10:24:10 GMT@Jonas H Ayende promised us Matco - a soup to nuts NHibernate app - THE WAY HE DOES IT - instead of complaining about other people's code, but like so much software, he failed to deliver once he showed a few screenshot. Heck anyone can do that. He's too busy complaining about other peoples code to complete his own projects.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment46http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment46Fri, 13 Jan 2012 01:51:28 GMT@Jimmy Final thought: I disagree. If the business rules are solely determined by the state of the data, as is such in my example, then IMO it fits the repository definition. I still think of that single customer as a logical data collection (just because it happens to only have one item has no bearing in this context). If I use the repository to add a new customer, this method still returns the newest customer from the entire logical customer data store. If I needed further business logic, eg all customers with pending orders and failed payment attempts or something, that would be a good candidate for an additional layer with dependencies on CustomerRepository, OrderRepository and PaymentRepository allowing me to query and aggregate data from those different data sources.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment45http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment45Thu, 12 Jan 2012 21:40:28 GMT@Scott you state, "would rather have it hidden behind a CustomerRepository.GetNewestCustomer(); method. The logic for getting the newest customer from the database could change (but you're right, probably not the actual data retrieval method, whether ORM or whatever). This way, any where I need to get this newest cutomer in the code from the database, I can always rely on the repository method, and not remembering how I wrote the query through the ORM... was it OrderByDescending()... I can't remember." What you are describing here is not best served by a repository pattern. The issue of what constitutes "a newest customer" is fundamentally a business rules issue, not one of data access. What you are probably wanting then is something closer to a query object or data access object that is the place where you can codify this rules (for instance does newest just mean the last row created or does it take into account the customer status where they must already be verified as well as a trite example). I haven't read too much through Oren's blog code yet but it appears his style is to leverage extension methods for this type of work. Either way there's a single place for wrapping this up, which was your primary concern it appears, but it's simply NOT a data layer responsibility.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment44http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment44Thu, 12 Jan 2012 18:55:17 GMT@cocowalla @Scott +1http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment43http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment43Thu, 12 Jan 2012 18:44:15 GMT@cocowalla, I agree completely. The current project I came into had exactly this problem. You also run into issues with determining the current active context since extension methods are static, which also prohibits your ability to easily inject dependencies for a current unit of work.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment42http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment42Thu, 12 Jan 2012 17:15:11 GMT@Omer Mor I'm not sure I like that - you could end up with so many extension methods that it ends up rather messy, and not exactly cohesive.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment41http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment41Thu, 12 Jan 2012 15:13:36 GMT@Scott: of course you don't want to clone complex pieces of data retrieval logic around your project. It should definitively reside in methods. but instead of using full blown repositories, you could use extension methods on your Session (or Session.Customers). http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment40http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment40Thu, 12 Jan 2012 14:10:44 GMT@Joao of course not. but still, not all applications need a denormalized reporting store etc and this is still a design principle that applies else where. http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment36http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment36Wed, 11 Jan 2012 22:16:42 GMTMy best argument for repositories has always been this: all database accessing code is in one place. If I have something like the (over simplified) following code: public ActionResult NewestCustomer() { return Session.Customers.OrderBy( x=> x.DateCreated).Take(1); } I would rather have it hidden behind a CustomerRepository.GetNewestCustomer(); method. The logic for getting the newest customer from the database could change (but you're right, probably not the actual data retrieval method, whether ORM or whatever). This way, any where I need to get this newest cutomer in the code from the database, I can always rely on the repository method, and not remembering how I wrote the query through the ORM... was it OrderByDescending()... I can't remember.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment35http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment35Wed, 11 Jan 2012 21:52:33 GMT@Alex, why would you test queries in isolation? Executing a LINQ statement may generate inefficient ugly SQL in one ORM but generate much better SQL in a different ORM. So trying to pretend the database is really just an in memory collection will prevent you from making these important optimizations. IMO this is better left to integration tests, and you can just use nhibernate+sqlite for this. @Marco, are you really using a single 3NF database for the entire enterprise? If so then this is the source of your friction.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment34http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment34Wed, 11 Jan 2012 21:48:23 GMT@Wayne depends upon which model you are referring to :) i personally do not expose my domain models that far up the stack. changes to a where clause is different than structural changes to an class. i would bet in most real world applications a specific model class is being references in multiple controllers and this is where you will see the change ripple throughout your project. again, for simple projects or a one man team this may not be that much friction, but for enterprise apps i would not dare take this approach http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment33http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment33Wed, 11 Jan 2012 21:30:26 GMTWhat about testing/faking without the repository approach?http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment32http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment32Wed, 11 Jan 2012 21:13:34 GMT@Marco: Correct me if I'm wrong but isn't the only reason for the controller to exist is to essentially map from the model to the view? If you directly reference an ISession in your controller with a LINQ query, then I would argue it's part of the controller's responsibility to decide what needs to be retrieved for display - if you change a *WHERE* clause in your LINQ code, this IMO **is** a valid reason for the controller to change, and adding an extra abstraction layer on top of it isn't buying you anything.http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment31http://ayende.com/153029/northwind-starter-kit-review-data-access-and-the-essence-of-needless-work-part-ii#comment31Wed, 11 Jan 2012 20:05:49 GMT