﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Morten Lyhr commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>As always you are a great inspiration. I think the Extension Methods naming could be improved if they are prefixed with Where.
  
  
I have blogged about it here: 
[morten.lyhr.dk/.../...discoverability-of-linq.html](http://morten.lyhr.dk/2011/04/reusability-and-discoverability-of-linq.html)</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment64</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment64</guid><pubDate>Thu, 14 Apr 2011 20:47:59 GMT</pubDate></item><item><title>Josh Stone commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>As the comments here have degenerated into a repository trash fest, I should point out that repositories aren't just for swapping implementations. That is the least of their usefulness.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment63</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment63</guid><pubDate>Thu, 24 Mar 2011 22:57:55 GMT</pubDate></item><item><title>Nick commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Just curious, what might this  .FilterAccordingToUserPermissions(CurrentUser) method look like.
  
  
thanks
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment62</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment62</guid><pubDate>Thu, 24 Mar 2011 20:45:02 GMT</pubDate></item><item><title>Jakub commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>I like idea of Code Symmetry: 
[aspnetresources.com/blog/achieving_code_symmetry](http://aspnetresources.com/blog/achieving_code_symmetry). When the query is placed just in the controler then the symmetry is disturbed:). So aggree with Clayton. Repositories are not about reusability but about structuring and testability.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment61</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment61</guid><pubDate>Thu, 24 Mar 2011 15:04:22 GMT</pubDate></item><item><title>Jimmy Zimms commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>@Augi
  
  
[Btw. your DAO (~IQueryable) leaks into your Domain (Specification) and this stinks a little bit for me - but if we suppose IQueryable as Repository then it's ok]
  
  
Augi, IQueryable actually isn't Data Acess, it's a form of specification pattern. e.g. Intention. Of course the specific IQueryProvider IS data access usually but as long as the interface abstraction is leveraged then it's not at all leaky.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment60</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment60</guid><pubDate>Wed, 23 Mar 2011 18:14:28 GMT</pubDate></item><item><title>Aaron commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>@Paul get a life.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment59</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment59</guid><pubDate>Tue, 22 Mar 2011 22:40:12 GMT</pubDate></item><item><title>Bunter commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Dunno what kind of apps you who all clap to Ayende write, but specification pattern for queries and service layer for complex updates has served me rather well over the time. Heck, even dao with app level interface ( the thing most of you call repository here ) Read operations are DB specific (fetchpaths for a start) and isolating this from the controller keeps latter sane plus makes query optimizing/avoiding duplication easier. Note: I usually work with apps that are maintained over several years
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment58</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment58</guid><pubDate>Tue, 22 Mar 2011 16:06:10 GMT</pubDate></item><item><title>Paul Cox commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>I would have loved to have had my university projects reviewed by one of the top programmers in the industry. You can guarantee I would be writing better code now.
  
  
I disagree that this is "beating a lightweight to death". Ayende is just showing some common problems in MVC applications using NHibernate by using an open-source example. Commercial enterprise applications tend not to be open source but if you are willing to post your code that would be really helpful because as you can see from the comments, a lot of professionals struggle with the issues highlighted in this series of blog posts and you seem to know what you are doing.
  
  
Finally, I'm not sure if you've done this already, but if you save your NHProf session to a file and send it to Ayende, I'm sure he will fix any issues and that would help everybody.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment57</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment57</guid><pubDate>Sat, 19 Mar 2011 13:47:32 GMT</pubDate></item><item><title>Sigmund commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>@Paul Cox It IS a bad thing when the angle is way off base. A student project doesn't aim to be a commercial project, and shouldn't be judged or criticised as one. I'd like to know how you'd feel if one of your student projects were dissected as if it were an enterprise application.
  
  
My point is very clear and valid; fight boxers in your own weight class, or above. There is no honour in beating a lightweight to death.
  
  
As for your NHibernate problems, N+1 issues are normal if you don't know what you're doing. I use an SQL profiler to monitor what NHibernate _really_ does. When using multi criterias/futures, filters and so on, NHProf isn't always up for the task.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment56</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment56</guid><pubDate>Sat, 19 Mar 2011 10:49:41 GMT</pubDate></item><item><title>Paul Cox commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Sigmund,
  
  
You act as if a *free* code review by one of the best developers on the planet (and associated discussion by a lot of professionals dealing with the same problems) is a bad thing! This is one of the best things that could happen to what already looks like a very promising student.
  
  
And I'm not sure what your code is doing with NHibernate but my code is pretty bad with hundreds of Select N+1 issues and NHProf handles it with ease. You must have same narly queries in there to be taxing NHProf!
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment55</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment55</guid><pubDate>Sat, 19 Mar 2011 09:02:02 GMT</pubDate></item><item><title>Sigmund commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Why are you picking on a student's project? The student in question has done a lot of things right, and of course a project is "over engineered" in a _university project_ - why wouldn't it be. At university you're supposed to try large scale techniques on small scale projects to experiment and learn.
  
  
The student has a promising career in front of him, but your public humiliation over a series of posts might hurt his career.
  
  
I advise you to use applications from seasoned professionals as examples. I've tried your NHibernate Profiler, and must say it's buggy (doesn't catch all queries), extremely slow and cpu intensive - why not write about your mistakes in creating that?
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment54</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment54</guid><pubDate>Sat, 19 Mar 2011 08:32:27 GMT</pubDate></item><item><title>Ayende Rahien commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Thomas,
  
[ayende.com/.../...s-got-to-justify-themselves.aspx](http://ayende.com/blog/archive/2009/09/28/even-tests-has-got-to-justify-themselves.aspx)</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment53</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment53</guid><pubDate>Fri, 18 Mar 2011 07:05:32 GMT</pubDate></item><item><title>Ayende Rahien commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Paul,
  
You should strive to have only a single transaction per the entire action.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment52</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment52</guid><pubDate>Fri, 18 Mar 2011 07:03:56 GMT</pubDate></item><item><title>gunteman commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>In-memory sqlite testing may not be perfect, but what are you comparing it to? A mocked repository is even more likely to behave differently.
  
  
I agree with the sentiments of the article, but I also agree that it would be so much better to see real examples of how it could be done better, rather than yet another "I'm smart, because they did it wrong" post. 
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment51</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment51</guid><pubDate>Thu, 17 Mar 2011 22:17:31 GMT</pubDate></item><item><title>Thomas Skovsende commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Ayende,
  
  
Is it just me that can't spot the unit tests in the Effectus and Alexandria code? I'm not sure I buy into the "unit testing" by using sqlite - there are enough differences between sqlite and "real" sql databases that you WILL have unexpected bugs.
  
  
And it's not really unit tests any more, but instead integration tests which is usually considerably slower. It might not matter in a small application, but it would quickly become too slow to run the tests all the time.
  
  
Do you have some examples that is developed without repositories in a TTD way?
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment50</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment50</guid><pubDate>Thu, 17 Mar 2011 16:39:06 GMT</pubDate></item><item><title>beto commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Grate post. But I think like most here I want to see some code. 
  
Anyway of releasing a sample app like alexandria but using asp.net mvc just like the code you are reviewing?
  
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment49</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment49</guid><pubDate>Thu, 17 Mar 2011 16:37:12 GMT</pubDate></item><item><title>oleksii commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>You seem to like the idea of command query segregation more and more ;)
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment48</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment48</guid><pubDate>Thu, 17 Mar 2011 16:04:55 GMT</pubDate></item><item><title>Paul Cox commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Thanks Ayende, what about opening the transaction? Can there be a single transaction from PostAuthenticate to the OnActionExecuted or should I just open multiple transactions?
  
  
For security I am evaluating Rhino.Security and trying to see how I can get it to work in the following situations from the view. i'm trying to bake some conventions into my security framework so that I don't need to keep specifying them throughout my project.
  
  
@Url.SecureAction("action", "controller") -&gt; Checks Rhino.Security /{controller}/{action} operation which accesses database from the view
  
  
@this.SecureForRole("Administrator", @&lt;div&gt;Admin section&lt;/div&gt;) -&gt; Not sure how to use Roles in Rhino.Security but currently checks custom Roles table from View. 
  
  
@foreach (var order in Model.Orders) {
  
    @* fields *@
  
    @Html.SecureActionLinkFor("/order/details", order)
  
    @Html.SecureActionLinkFor("/order/edit", order)
  
}
  
  
I think I may be missing something obvious!
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment47</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment47</guid><pubDate>Thu, 17 Mar 2011 12:20:38 GMT</pubDate></item><item><title>Jamie Ide commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>I would like to offer a mild defense of repositories. First I want to wholeheartedly agree that the generic repository and the repository-per-class pattern are useless crap.
  
  
I have a medium-size Windows Forms application that is about 10 years old (was originally in Delphi) and does not use MVP/MVC or any UI pattern consistently. Extracting the data access methods into repository classes was the only practical way for me to introduce integration testing. I also find it helpful for code organization, and I don't care if each method is only used once. The ISession is used directly for Get/Load but anything more involved (HQL or Criteria API) is in a repository that requires an ISession in its constructor (transactions are controlled by the UI). This works great for us.
  
  
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment46</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment46</guid><pubDate>Thu, 17 Mar 2011 12:03:34 GMT</pubDate></item><item><title>Matt commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>This was a really interesting post, thanks.
  
  
I do have one argument for the Repository pattern, however.  One thing I like about it is that you can tailor it more to your domain as a layer of the data access model which can make it easier for users of your applications business logic layer easier to understand.  For example, if you have a readonly table - don't expose a Save method.  Only relevant access methods are exposed, and gives a better understanding of the underlying data.
  
  
Further, the prefetch paths are easy to overcome by exposing enumerations of allowed prefetch "queries".  These can be passed as params and is not rocket science to implement.
  
  
Finally, the implementation of this layer takes away the underlying data source dependency - this has been invaluable to me in the past when switching an application over from a relational database to a document database - my application didn't have to change at all.
  
  
All in all, I agree with your sentiments but I'm not prepared to throw out the repository pattern quite yet!
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment45</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment45</guid><pubDate>Thu, 17 Mar 2011 11:48:24 GMT</pubDate></item><item><title>Ayende Rahien commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Pedro,
  
You seem to have missed the point, this post is primarily about READS, not writes.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment44</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment44</guid><pubDate>Thu, 17 Mar 2011 11:47:54 GMT</pubDate></item><item><title>Ayende Rahien commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Betty,
  
Yes, of course.
  
Take a look at the Effectus and Alexandria sample applications.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment43</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment43</guid><pubDate>Thu, 17 Mar 2011 11:47:23 GMT</pubDate></item><item><title>Ayende Rahien commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Paul,
  
I _really_ don't want to have a session available for the view. It leads to lazy loading in the view. But I don't care where you _open_ the session.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment42</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment42</guid><pubDate>Thu, 17 Mar 2011 11:41:27 GMT</pubDate></item><item><title>Pedro commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Hi Ayende,
  
  
I must agree with you that sometimes it's best to access ISession rather then the repository, specially for queries. And after reading your previous post my question is what is your strategy for other repository actions like save for instance. For sure it's not desirable to let every developer write it's own save method, specially in large business applications, and sometimes it's not as straightforward as a single call to Session.Save for instance, so how do you encapsulate that logic outside a repository?
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment41</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment41</guid><pubDate>Thu, 17 Mar 2011 11:16:50 GMT</pubDate></item><item><title>Betty commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>I see a lot of "how to do it wrong" posted on this blog, but never really much info on a project that's done it right. Do you have any examples of projects you've actually thought were done well?
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment40</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment40</guid><pubDate>Thu, 17 Mar 2011 11:05:54 GMT</pubDate></item><item><title>Paul Cox commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>How do you manage the NHibernate session and transaction when security becomes involved in an MVC application? I want to load my user in the PostAuthenticate method and also check permissions in the view. Is it okay to have a single NHibernate session and transaction open from PostAuthenticate to after the view result has executed?
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment39</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment39</guid><pubDate>Thu, 17 Mar 2011 10:44:37 GMT</pubDate></item><item><title>Bikal Gurung commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>HI Ayende,
  
  
I agree with your assertion completely. Having a repository abstraction layer when used in conjunction with ORMs like nhibernate is just needless and a sign of bad abstraction. They donot provide for any useful technical benefits. As such they just acts as noise making the system difficult to understand and thus maintain or refactor.
  
  
Well said.
  
  
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment38</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment38</guid><pubDate>Thu, 17 Mar 2011 10:42:37 GMT</pubDate></item><item><title>Ayende Rahien commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Steve,
  
I already did:
  
[ayende.com/.../...sitory-is-the-new-singleton.aspx](http://ayende.com/Blog/archive/2009/04/17/repository-is-the-new-singleton.aspx)  
[ayende.com/.../...y-util-amp-common-libraries.aspx](http://ayende.com/Blog/archive/2009/04/29/let-us-burn-all-those-pesky-util-amp-common-libraries.aspx)  
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment37</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment37</guid><pubDate>Thu, 17 Mar 2011 07:39:51 GMT</pubDate></item><item><title>Ayende Rahien commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>Tyler,
  
Whenever you are calling commit, you are doing a lot of work on the session level.
  
When you are doing that in this fashion, it means:
  
a) You are making calls outside of a transaction all the time.
  
b) It is _highly_ likely that you are making use of multiple transactions in the same action for no real good reason.
  
  
For the example that you gave, NHibernate can optimize your actions so it never have to talk to the database at all.
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment36</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment36</guid><pubDate>Thu, 17 Mar 2011 07:36:14 GMT</pubDate></item><item><title>naraga commented on Architecting in the pit of doom: The evils of the repository abstraction layer</title><description>@Russ
  
ah those future generations - what about global warming - are you driving prius already? ;)
  
just kidding. i think that ORM like NH is kind of framework you can safelly consider to be corepart of your app and depend on it very tightly.
  
you dont want to abstract .NET, right?
  
  
btw. i have used Repository heavylly in pre-NH era and it is very usefull. now the only reason i see is to make conversions to IEnumerable  :)
  
</description><link>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment35</link><guid>http://ayende.com/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer#comment35</guid><pubDate>Thu, 17 Mar 2011 07:05:20 GMT</pubDate></item></channel></rss>