Comments on: ActiveRecord, the ugly design pattern http://damieng.com/blog/2007/05/07/activerecord-the-ugly-design-pattern?utm_source=rss&utm_medium=rss&utm_campaign=activerecord-the-ugly-design-pattern A .NET developer in silicon valley Sun, 25 Dec 2011 15:10:30 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Jimmy Zimms http://damieng.com/blog/2007/05/07/activerecord-the-ugly-design-pattern#comment-29199 Jimmy Zimms Wed, 04 Nov 2009 16:29:01 +0000 http://damieng.com/blog/archive/2007/05/07/activerecord-the-ugly-design-pattern.aspx#comment-29199 Millions years too late but what the hell, why not post? ;) It behooves me to mention that most of the time I happen to see Active Record pattern actually in use by non trivial applications is actually as a bridge between domain layers and an ORM itself. While being able to reconstitute a domain entity from the ORM and gain all the tastey wonderfullness that comes with it (auto session management, entity maps, less code, and now query providers) so far all the major vendors still all leak nondomain requirements into the objects, namely the requirement for a parametereless constructor and virtual and/or writeable properties. For some people this is a make or break issue so they bridge them via AR. That of course opens another can of worms but I can totally see where some people are coming from. Millions years too late but what the hell, why not post? ;)

It behooves me to mention that most of the time I happen to see Active Record pattern actually in use by non trivial applications is actually as a bridge between domain layers and an ORM itself. While being able to reconstitute a domain entity from the ORM and gain all the tastey wonderfullness that comes with it (auto session management, entity maps, less code, and now query providers) so far all the major vendors still all leak nondomain requirements into the objects, namely the requirement for a parametereless constructor and virtual and/or writeable properties. For some people this is a make or break issue so they bridge them via AR. That of course opens another can of worms but I can totally see where some people are coming from.

]]> By: steve http://damieng.com/blog/2007/05/07/activerecord-the-ugly-design-pattern#comment-1841 steve Mon, 14 May 2007 20:11:18 +0000 http://damieng.com/blog/archive/2007/05/07/activerecord-the-ugly-design-pattern.aspx#comment-1841 It's not ActiveRecord that's ugly, it's the implementation of it. Whether or not to make the 'finder' methods static or put them in another, single-instance class is stylistic more than anything else - in both cases the implementations should be using a more generic implementation to do things like cacheing - whether that's done through delegation or inheritence will influence where you put those methods. I've seen it done both ways and both are adequate. Static methods of any kind are inherently a separation of responsibility, since by nature they cannot be instance-sensitive. Not using them in this case because of that actually implies that they should never be used. In fact static methods are useful where the implementation is domain-specific but not state-specific. Finder methods can actually fit that description, depending on implementation, although arguably because they all do similar things they would be better placed in an external class with policy / attribute-oriented behaviour rather than a domain-specific location. <br /><br />ActiveRecord works well as a pattern for simple stuff, but even in larger systems you'll probably find that a reasonable proportion of your classes fit it ok. Therefore being able to mix it with more complex mappings is the most pragmatic approach - have an automatic mapping for those that can use it, and manual mapping otherwise. <br /><br />Also, since overly deep inheritence structures can be limiting in their own right (the age old example of Person and subclasses Employee and Customer, but what happens if your employee is also a customer sometimes .. doh), I actually find that data inheritence is less of a problem in practice than it is in theory. Where it is necessary to have data inheritence, a case-by-case approach tends to be best rather than blanket application of one pattern. After all, it depends on the data mix / distribution as to which will be most appropriate - STI will be fine if there's only one or two small attributes, one of the other two will be more useful when there are bigger differences. And if you mapper is smart enough, you can switch between them if the data mix changes as the application evolves.<br /><br /> It’s not ActiveRecord that’s ugly, it’s the implementation of it. Whether or not to make the ‘finder’ methods static or put them in another, single-instance class is stylistic more than anything else – in both cases the implementations should be using a more generic implementation to do things like cacheing – whether that’s done through delegation or inheritence will influence where you put those methods. I’ve seen it done both ways and both are adequate. Static methods of any kind are inherently a separation of responsibility, since by nature they cannot be instance-sensitive. Not using them in this case because of that actually implies that they should never be used. In fact static methods are useful where the implementation is domain-specific but not state-specific. Finder methods can actually fit that description, depending on implementation, although arguably because they all do similar things they would be better placed in an external class with policy / attribute-oriented behaviour rather than a domain-specific location.

ActiveRecord works well as a pattern for simple stuff, but even in larger systems you’ll probably find that a reasonable proportion of your classes fit it ok. Therefore being able to mix it with more complex mappings is the most pragmatic approach – have an automatic mapping for those that can use it, and manual mapping otherwise.

Also, since overly deep inheritence structures can be limiting in their own right (the age old example of Person and subclasses Employee and Customer, but what happens if your employee is also a customer sometimes .. doh), I actually find that data inheritence is less of a problem in practice than it is in theory. Where it is necessary to have data inheritence, a case-by-case approach tends to be best rather than blanket application of one pattern. After all, it depends on the data mix / distribution as to which will be most appropriate – STI will be fine if there’s only one or two small attributes, one of the other two will be more useful when there are bigger differences. And if you mapper is smart enough, you can switch between them if the data mix changes as the application evolves.

]]> By: dies-el http://damieng.com/blog/2007/05/07/activerecord-the-ugly-design-pattern#comment-1840 dies-el Tue, 08 May 2007 23:19:41 +0000 http://damieng.com/blog/archive/2007/05/07/activerecord-the-ugly-design-pattern.aspx#comment-1840 Hey Damieng,<br /><br />I believe Rails achieves Single Table Inheritance by adding an extra column (named 'type') to the table that lets rails know what model to use for what data. The model classes you then make use that invisibly to make sure they access the correct data.<br /><br />On a side note, the Rails book (Agile Web Develoblah, pg 341) does carry lots of warnings as to whether you should actually use STI or whether you should go for another method of categorising (e.g. tagging). Hey Damieng,

I believe Rails achieves Single Table Inheritance by adding an extra column (named ‘type’) to the table that lets rails know what model to use for what data. The model classes you then make use that invisibly to make sure they access the correct data.

On a side note, the Rails book (Agile Web Develoblah, pg 341) does carry lots of warnings as to whether you should actually use STI or whether you should go for another method of categorising (e.g. tagging).

]]>