http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660No, I am saying that when deciding to use AR pattern, you should consider your actual use case scenario. http://ayende.com/4624/moving-away-from-the-active-record-model#comment12http://ayende.com/4624/moving-away-from-the-active-record-model#comment12Tue, 14 Sep 2010 21:50:58 GMTSo what your saying is Castle Active Record is ok so long as you don't use the Active Record? I would argue that UOW and AR are not mutually exclusive. UOW is a at higher level of abstraction and categorized by Fowler as a behavioral pattern. AR and Data Mapper(Repository) are categorized as architectural patterns that sit lower in the stack. A UOW manager can call the AR persistence methods or repository methods and still function logically the same. http://ayende.com/4624/moving-away-from-the-active-record-model#comment11http://ayende.com/4624/moving-away-from-the-active-record-model#comment11Tue, 14 Sep 2010 17:38:55 GMT@Dmitry, It depends - the schema implied by an Active Record pattern doesn't preclude more advanced features. But the definition given at the start of the blog post - "An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data." - does. You're working off of a different understanding of the pattern than the one described by Ayende - in the version of the pattern he's described, persistence operations only exist in single-row flavors. Once you start talking about ActiveRecord implementations that support more sophisticated optimizations, many of his criticisms no longer apply. http://ayende.com/4624/moving-away-from-the-active-record-model#comment10http://ayende.com/4624/moving-away-from-the-active-record-model#comment10Mon, 13 Sep 2010 15:22:06 GMTI do not think the Active Record pattern implies that you cannot have nested graphs, batching or transactions that span over multiple operations. It means that a class represents a table and an object represents a row. Persistence operations do not have to be used on a row-per-row basis except for simpler cases. And there could be a query language as well or an ability to materialize graphs from an SQL query. http://ayende.com/4624/moving-away-from-the-active-record-model#comment9http://ayende.com/4624/moving-away-from-the-active-record-model#comment9Sat, 11 Sep 2010 16:04:21 GMTJustin, Castle ActiveRecord offers you several choices, you can use it with a Unit of Work or AR. http://ayende.com/4624/moving-away-from-the-active-record-model#comment8http://ayende.com/4624/moving-away-from-the-active-record-model#comment8Sat, 11 Sep 2010 12:29:44 GMTHelp me understand how you compare a pattern (Active Record) directly to a generic term for a tool (ORM)? Active record is a pattern that an ORM can implement. NHibernate is a specific ORM that instead implements a repository pattern. Castle is a ORM that implements the Active record pattern, it uses Nhibernate and and therefore the repository pattern internally, but that is an implementation detail, like using a relational database for a key value store. Criticizing the Active record pattern also criticizes any implementation of that pattern, including Castle, how can you make the distinction? You are criticizing the pattern as a whole not just one implementation right? http://ayende.com/4624/moving-away-from-the-active-record-model#comment7http://ayende.com/4624/moving-away-from-the-active-record-model#comment7Fri, 10 Sep 2010 18:17:56 GMT@Alex Active Record, both pattern and implementation are good. Oren is working in a context where the ActiveRecord pattern inhibits simplicity, rather than enhances it. Like Oren said, the implementation of AR (Castle) and concepts of AR are 2 distinct things. Castle AR uses NH to implement the AR pattern. You also need to consider the context/application you are designing. True DDD only applies to small percentage of projects where the AR pattern doesn't make sense. There is still a large market/code base for simpler AR designs. After all MS is still making forms over data frameworks like lightswitch :) Oren's view makes sense for the context in which he works. http://ayende.com/4624/moving-away-from-the-active-record-model#comment6http://ayende.com/4624/moving-away-from-the-active-record-model#comment6Fri, 10 Sep 2010 12:22:21 GMTSo Castle.ActiveRecord is still good? http://ayende.com/4624/moving-away-from-the-active-record-model#comment5http://ayende.com/4624/moving-away-from-the-active-record-model#comment5Fri, 10 Sep 2010 11:57:30 GMTDaniel, Make a distinction between the Active Record _pattern_ and the Castle.ActiveRecord project. http://ayende.com/4624/moving-away-from-the-active-record-model#comment4http://ayende.com/4624/moving-away-from-the-active-record-model#comment4Fri, 10 Sep 2010 09:39:41 GMTOh noes! I just come to the moment where I have a very good knowledge of Castle AR + NHibernate ICriteria to use them succesfully and efficiently in my projects and now you say that AR is not good anymore? :)) http://ayende.com/4624/moving-away-from-the-active-record-model#comment3http://ayende.com/4624/moving-away-from-the-active-record-model#comment3Fri, 10 Sep 2010 09:36:51 GMTThe implementation of Active Record which Rails uses is a good example of this; the Arel relational algebra allows composition of queries in a pretty elegant way. They've extended the AR pattern out into something much more appropriate for advanced scenarios. http://ayende.com/4624/moving-away-from-the-active-record-model#comment2http://ayende.com/4624/moving-away-from-the-active-record-model#comment2Fri, 10 Sep 2010 09:24:04 GMTMy feelings exactly. The kind of use cases I'm working with would be complicated as hell in an Active record pattern, and would make for some very ugly code. Using a full ORM (Hibernate in our case) really alleviates all of that. http://ayende.com/4624/moving-away-from-the-active-record-model#comment1http://ayende.com/4624/moving-away-from-the-active-record-model#comment1Fri, 10 Sep 2010 09:21:16 GMT