http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I love the focus on simplicity at the moment and cutting down all the architecture crap and abstraction madness. Please write more stuff along the lines of this - you are a respected individual and have some weight in a lot of companies. You are saving us from architecture tyranny. @Dev ... Oh also without wishing to piss anyone off, Scott Millet's book (Professional ASP.Net Design Patterns) was a hopeful purchase by myself. It's actually full of leaky, messy abstractions, epic violations of SOLID and all sorts of incongruent mess. I don't like it at all. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment53http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment53Wed, 23 Mar 2011 10:28:26 GMTDude, with this one you made me laugh for half an hour. How is call this? over-f.... architecture? :-) http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment52http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment52Tue, 22 Mar 2011 16:13:38 GMTDmitry's repo is close to what I use. Basically IRepository <t is just IQueryable <t plus InsertOnSubmit and DeleteOnSubmit. You only need one concrete class (like LinqRepository <tentity,> ). It's useful for a few reasons: 1. if you have true repeated / shared query logic, you can model that as extension methods from IQueryable <t to IQueryable <t (specs are now easy to test with List or whatever) 2. you can use the IRepo as IQueryable in your controllers if you don't need the abstraction and you are fairly close to your persistence 'metal' 3. you can have concrete classes for other persistence strategies as long as they provide IQueryable. My scenario here was a mainframe integration product that spoke Entity Framework. We could have our main persistence done with linqtosql or nh but use a consistent repository model to talk to the mainframe integration piece. >http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment51http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment51Mon, 21 Mar 2011 21:43:12 GMTHave encountered the useless layer abstraction madness in my last company - so much that I had to leave and emigrate to another country in disgust :) Surprised how easily the .NET community give enough ammo to every developer to shoot themselves in the foot. Almost every other guy I have interacted wants to live and breathe fluent lambda syntax and is trying to get fancy with expression trees and fancy abstraction layers. Wonder how many developers in say the Python world want to write a meta class? I think we generally tend to leave meta class programming to the people who know what they are doing, and are happy building out features. Six months into Django quite happy with the queryset api and not yet felt the urge to wrap it in a repository. On a final note, on the earlier post about not having common libraries - I'd rather have all the crap I've written over the years (or whatever that is my colleague is snickering at) in a single assembly than 10 different ones. And by the way the abstraction guys got promoted, and I had to search for a job - maybe abstractions are there for a reason :) http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment50http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment50Mon, 21 Mar 2011 06:09:10 GMT@Gunteman - Care to explain your position further? Sharp Architecture has actually changed little since the first release by Billy. Major changes are underway now, but every project evolves over time, do they not? http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment49http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment49Sun, 20 Mar 2011 00:59:22 GMT@Dominic, Your repository object looks more like a DAO/service. A repository (in DDD) is supposed to be collection-like abstraction of aggregate root entities. That means you are not supposed to have custom implementations and methods for specific entity types. It should be thought more like IEnumerable<TEntity> I do not think Ayende is against abstracting data access code in DAO classes that use NHibernate API through dependency injection. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment48http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment48Sat, 19 Mar 2011 15:35:20 GMT@Ayende, An indexer is just a convention developers are used to. I forgot to remove it (since it is irrelevant to the discussion) that's why I created another post. It would be a Load or a Get overload if I was designing a public API. I am not sure what you mean by "depending on NH API everywhere else"? The unit-of-work interface contains SubmitChanges(), Dispose(), Attach(), Detach(), Merge() methods and a T4 generated partial class with repository properties such as IRepository<Company> Companies { get; }. A controller subclass is responsible for starting, committing and disposing the unit-of-work. Granted there are queries that had to be done using Criteria API. Those are abstracted in classes that use the underlying NHibnerate session through DI. Hopefully as NHibernate evolves most of them would be possible to do with LINQ. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment47http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment47Sat, 19 Mar 2011 15:29:48 GMT@Ayende Rahien Since you are so anti-repository, could you suggest what we should do instead (maybe a blog post on it). For instance, are you advocating that we should do this (for an ASP.NET MVC app): public ActionResult ListProducts(string search) { ISession session = // Get session somehow ITransaction tx = session.BeginTransaction(); IQuery query = session.CreateQuery("select p from Product as p where p.Name like :name"); query.SetString("name", "%" + search + "%"); IList <product products = query.List <product(); tx.Commit(); session.Close(); return View(products); } If not, then what? This is how I would write out the above with Repositories: public ActionResult ListProducts(string search) { IList <product products = _productRepository.SeachProducts(string search); return View(products); } Seems much cleaner to me, data access code is neatly encapsulated away, doesn't violate SoC or DRY, what's wrong with it? How would you approach it differently? To quote E. Dijlstra: "The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise" >http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment46http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment46Sat, 19 Mar 2011 15:25:59 GMTIn the end all the discussion is for a simple reason...some years ago you and others told us to do things with Repositories and abstraction layers etc. Nowadays all of this is suddenly false. You have to admit that this is a little confusing. So my conclusion is...i do it in a way that seems to be right for me and my projects. So for instance I like the idea of abstracting NH away from the rest of my code. This is not only to have the ability to change the OR/M in the future but to have on simple an clear API every team developer can simply understand and use and I do not see why this should be bad. Using NH directly in view's or something else remembers me of times ten years ago. But who cares, it is a free world and everyone can do what he wants. But you're right, there is no need to overcomplicate things like in the example above. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment45http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment45Sat, 19 Mar 2011 13:43:38 GMTDmitry, Get & indexer are bad for you, you should have clearer semantics. Get & Load are better terms. As for the rest, I really don't see what this gives you. Especially since you rely on the rest of the NH API elsewhere. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment44http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment44Sat, 19 Mar 2011 06:59:37 GMTThe indexer is used for lazy loading proxies - a convention from the old system. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment43http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment43Sat, 19 Mar 2011 06:30:23 GMTHere is my implementation of repository. There is only one interface and one implementation class. Both, repository and find methods work with IQueryable so Fetch, Cachable, Skip, Take, OrderBy, additional Where clauses and any other LINQ/Nhibernate extension methods can be applied on the query level. Specifications are only used in cases where the Where lamdba expression would be difficult to understand. It could be customer categorization, accounting rules, etc. public interface IRepository<T, in TKey> : IQueryable<T> where T : Entity<TKey> { T this[TKey id] { get; } T Get(TKey id); IQueryable<T> Find(ISpecification<T> specification); object Add(T entity); void Remove(T entity); void RemoveById(TKey id); void Refresh(T entity); } http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment42http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment42Sat, 19 Mar 2011 06:29:03 GMTHmmm... When i started taking photos and bought my first camera, the first I did was to put an uv filter to "protect" my lens... I used it until a good friend and photographer of mine asked me: why would you spend so much money to buy a first class lens, just to put some crappy glass on top of it... Smart people put so much effort to get rid of SQL, only to end up like this. Why go all this trouble to come up with something as good as hibernate just to shadow it with patterns like this? What is a pattern anyway??? http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment41http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment41Sat, 19 Mar 2011 01:50:45 GMTMy current approach is to load aggregate root from repository, modify and save it, applying a nestable Transaction attribute on the calling method. For views, criteria API or an sql-query do an excellent job loading view models directly from db using an imported class, I use sharparchitecture on this project without any friction and the benefit it provides are great (I am a bit biased though), but I rarely end up with repository classes like EmailTemplateRepository. Regarding the specification pattern used in WCHM, I have tried it once with the NH2.1 unofficial nhibernate linq provider, and was limited by it's lack of functionality, but I quite liked the idea of chaining specifications and it made mocking the repository much easier. Looking forward to reading the rest of the posts. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment40http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment40Sat, 19 Mar 2011 01:17:03 GMTNice video about the best practices subject [exposureroom.com/.../1fc0a77839354170a009e6bcaf...](http://exposureroom.com/members/irascian/1fc0a77839354170a009e6bcaffa868c/)http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment39http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment39Fri, 18 Mar 2011 23:59:15 GMThumm Learning how not do something is very cool and important... but where is the counter part? The "how to do things"? http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment38http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment38Fri, 18 Mar 2011 23:55:06 GMT@pete w To be fair, the stuff outlined in Billy's original article have very little to do with the generic repository stuff that's debated now. SharpArchitecture has quite a few nice concepts and I believe it started out as a good intentioned "reduce friction" project, but architecture took over and it's now becoming less and less relevant as a good framework. I agree about ActiveRecord. When it works well it's productivity heaven. The "persistence ignorance" mantra managed to almost kill it, but it is indeed a working approach in many scenarios. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment37http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment37Fri, 18 Mar 2011 22:41:17 GMTAhh I see, I didnt realize we were actually critiquing SharpArchitecture here! I knew the design above looked familiar! The origin of the design above can be traced back to "NHibernate best practices" article on codeproject By Billy Mccafferty. ( [www.codeproject.com/.../...rnateBestPractices.aspx](http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx)) Billy's article was largely accepted as "this is how you do NHibernate with ASP.NET" for many years so its funny to me seeing so many people in this forum taking digs at that design today. @Ayende I cannot disagree the "templated generic repository" approach above can make you paint yourself into a corner when using stateful session-aware persistence like EF or NH. ActiveRecord always worked for me in these scenarios http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment36http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment36Fri, 18 Mar 2011 20:26:19 GMTI am implementing a new project, and originally I had a light-weight repository for querying only. This has since been replace with a pattern which looks very much like this and I can see that there will be an explosion of repositories and worse, repositories which look very similar containing just one find by id method. This anti-pattern is definitely not the way to go, but I'm dead against using the object context directly, I'd like to keep track of what queries I am executing. Doesn't have to be complicated though. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment35http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment35Fri, 18 Mar 2011 20:24:43 GMTDominic, Exactly what I meant, the calling code knows more than the repository method. The usual method to handle that is to manage the transaction in the same place as the session. Passing an ITransaction to the method makes _everything_ that much harder. Now you have overloads to handle that, and you have to take special note when the user is passing the transaction, etc. And, of course, if by any chance you didn't think of that, you end up with multiple transactions per request, which means that you basically lost the basic transactional guarantee, that is is all or nothing. Then there is the issue that this code implies that you are reading outside of transaction, of course. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment34http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment34Fri, 18 Mar 2011 16:29:05 GMT@Jeff " Start transaction at start of web request, commit at end?" I've never bought into this for managing transactions. Surely it is driven by context, but that's a little long lived for me. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment33http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment33Fri, 18 Mar 2011 16:28:10 GMT@Jeff Sternal I disagree, putting them in the Repository puts them in the right place for 90% of times when you just want to save something and don't really need transaction management. For those times when you need more fine grained control of Transactions, you can still have the caller get an instance of ITransaction and manage it. @Jeff Sternal and @Ayende Rahien I should point out that I'm using the Session per Request pattern (it's a web application), which is recommended practice according to the official NHibernate docs (they even provide some sample code for it). I know it smacks of utility class with SessionManager.GetSession(), it was a simplified example, my code doesn't quite look like that. Also, what do you mean by "That is the responsibility of the context,not your code"? Do you mean as in request context (for a web app) e.g. Start transaction at start of web request, commit at end? http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment32http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment32Fri, 18 Mar 2011 16:21:21 GMTPete, Sure, let us talk about 100+ entities in this manner. You have a classic case of parallel class hierarchies, a known worst practice. Your repository makes a lot of assumptions about the underlying data storage, assumptions that you are usually can't really escape. For example, the notion that you can query on associated entities, which is usually a bust when using a docuemnt database. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment31http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment31Fri, 18 Mar 2011 16:13:43 GMTDominic, a) NHibernate already defines the Save method. b) Your likely implementation of the session is _horrible_, based on the code that you have provided. You don't manage transactions manually. That is the responsibility of the context,not your code. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment30http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment30Fri, 18 Mar 2011 16:06:29 GMT@Jeff I like to begin and commit my transactions in the application layer where i have various handlers for each business process/command. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment29http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment29Fri, 18 Mar 2011 15:43:48 GMTEr, just to clarify what I wrote above - the alternative to: _customerRepository.Save(customer); Isn't even to write out GetSession, BeginTransaction for every operation. Instead, you can push session and transaction management out (for example into request event handlers, action filters, etc..), so that ultimately you're deciding between the code above and: session.SaveOrUpdate(customer); http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment28http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment28Fri, 18 Mar 2011 15:37:34 GMTOren - good to see you post your comments on this as well as see the others opinions. The Sharp Architecture team is in the middle of re-writing a lot of this code, as well as removing quite a bit of the indirection that is found in the repository area. Part of the problems we saw was that we had IRepositoryWithTypeId <t,> , then IRepository <t that implemented the former. Then there were 4 concrete implementations on top of these. This is now going away - which ironically occurred about the same time as your original posting. I am a fan of a generic repository interface for the simple fact I can leverage it to place different persistence mediums behind it, in this case NHibernate and RavenDb (new in 2.0). But what we found is that the concrete implementation for IRepositoryWithTypeId, RepositoryWithTypeId, was completely specific to Nhibernate, even though there was a NHibernateRepositoryWithTypeId as well. I agree with a lot of what is being said, and once again thank the commenter's for speaking up. If you have any other feedback, negative or positive, I would love to hear it and potentially learn from it. Thanks Alec Whittington Sharp Architecture >http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment27http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment27Fri, 18 Mar 2011 15:36:29 GMTIt would be interesting to see your take on NerdDinner (at CodePlex), that project is not NHybernate (it's LINQ2SQL and EF depending on version). But that project is actually used (in books) to teach people about Microsoft MVC and QRM integration with it. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment26http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment26Fri, 18 Mar 2011 15:29:02 GMT@Dominic - there are several reasons to prefer writing out GetSession, BeginTransaction, etc.. But the biggest one is that hiding them inside the repository puts session and transaction management in the wrong place; callers know best how to scope them. http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment25http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment25Fri, 18 Mar 2011 15:24:40 GMTThat makes me feel better. I shirked away from trying Sharp Architecture when it was gaining momentum a few years ago, for pretty much the same reason. All that "stuff" weighing on my brain. I think it had some reasonable selling points, but I'm too lazy to get my head around stuff and write lots of code :) http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment24http://ayende.com/4786/the-wages-of-sin-over-architecture-in-the-real-world#comment24Fri, 18 Mar 2011 15:17:06 GMT