Comments on: Castle’s ActiveRecord: Not for the Domain Purist in you… http://lostechies.com/nelsonmontalvo/2007/04/17/castle-s-activerecord-not-for-the-domain-purist-in-you/ Just another LosTechies site Thu, 24 Mar 2011 19:28:33 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: nmonta76 http://lostechies.com/nelsonmontalvo/2007/04/17/castle-s-activerecord-not-for-the-domain-purist-in-you/#comment-21 nmonta76 Thu, 26 Apr 2007 16:29:42 +0000 /blogs/nelson_montalvo/archive/2007/04/16/castle-s-activerecord-not-for-the-domain-purist-in-you.aspx#comment-21 I was experimenting with ActiveRecord, an implementation of the pattern built on top of NHibernate. As it is, the pattern itself can occasionally serve the purpose from a DDD point of view. Afterall, I can have domain objects that map directly to tables, right? And my domain objects can - under the covers - deal with the database. As long as that work is not directly exposed to my domain in some form such as domainObject.InsertIntoSqlDatabase(). However, tagging my domain object itself with persistence concerns does bother me. The cool thing is that ActiveRecord (the tool) does provide the ActiveRecordMediator object. This allows for us to take more of a repository approach. I did not make that clear in my last statement. Sorry. I was experimenting with ActiveRecord, an implementation of the pattern built on top of NHibernate.

As it is, the pattern itself can occasionally serve the purpose from a DDD point of view. Afterall, I can have domain objects that map directly to tables, right? And my domain objects can – under the covers – deal with the database. As long as that work is not directly exposed to my domain in some form such as domainObject.InsertIntoSqlDatabase().

However, tagging my domain object itself with persistence concerns does bother me. The cool thing is that ActiveRecord (the tool) does provide the ActiveRecordMediator object. This allows for us to take more of a repository approach. I did not make that clear in my last statement. Sorry.

]]> By: mawi http://lostechies.com/nelsonmontalvo/2007/04/17/castle-s-activerecord-not-for-the-domain-purist-in-you/#comment-20 mawi Thu, 26 Apr 2007 08:07:01 +0000 /blogs/nelson_montalvo/archive/2007/04/16/castle-s-activerecord-not-for-the-domain-purist-in-you.aspx#comment-20 Sidenote: Why use an active record implementation if you dislike the architectural *pattern*? (The PoEEE summary of the pattern: "An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.") Sidenote: Why use an active record implementation if you dislike the architectural *pattern*?

(The PoEEE summary of the pattern:
“An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.”)

]]> By: agilejoe http://lostechies.com/nelsonmontalvo/2007/04/17/castle-s-activerecord-not-for-the-domain-purist-in-you/#comment-19 agilejoe Tue, 17 Apr 2007 19:22:11 +0000 /blogs/nelson_montalvo/archive/2007/04/16/castle-s-activerecord-not-for-the-domain-purist-in-you.aspx#comment-19 It's not that I am am totally against active record. I am sure it has it's place in certain applications. But from an enterprise perspective the fact that I am decorating my domain with persistence layer artifacts, just doesn't sit well with me. But if RAD is what you want then AR is the way to go. Cheers! It’s not that I am am totally against active record. I am sure it has it’s place in certain applications. But from an enterprise perspective the fact that I am decorating my domain with persistence layer artifacts, just doesn’t sit well with me. But if RAD is what you want then AR is the way to go.

Cheers!

]]> By: Ayende Rahien http://lostechies.com/nelsonmontalvo/2007/04/17/castle-s-activerecord-not-for-the-domain-purist-in-you/#comment-18 Ayende Rahien Tue, 17 Apr 2007 13:52:39 +0000 /blogs/nelson_montalvo/archive/2007/04/16/castle-s-activerecord-not-for-the-domain-purist-in-you.aspx#comment-18 1/ You don't need to inherit from ARBase<T> 2/ You can specify that you want the OR/M to go directly against the fields, instead of using properties. 3/ I don't have a problem with the properties, they are not actionable, they are declarative, and I find that it is usually faster than writing the info in XML. 1/ You don’t need to inherit from ARBase
2/ You can specify that you want the OR/M to go directly against the fields, instead of using properties.
3/ I don’t have a problem with the properties, they are not actionable, they are declarative, and I find that it is usually faster than writing the info in XML.

]]>