SitePoint Sponsor

User Tag List

Results 1 to 14 of 14

Hybrid View

  1. #1
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)

    Doesn't the 'Active Record' pattern suck?

    I have a great idea: let's combine data access, domain logic and a tight coupling with the DB schema.
    I haven't actually used the Active Record pattern, but that's what it seems like to me.
    Has anyone built big apps with RoR(or other) making heavy use of the Active Record pattern?
    Did you ever use this pattern in an app and at some point started wishing(RoR's users??) that you had used something like a Data Mapper instead?

  2. #2
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I see the data mapper pattern being useful if:
    • You change data stores frequently
    • You have to make your objects work with many data stores at once
    • Your data mapper objects and models are on separate machines.

    If none of these apply, then what's the benefit of data mapper over active record? For example, at work I know we're never going off SQL Server for the lifetime of the apps I'm building. Wouldn't the data mapper pattern just be premature optimization at that point?

  3. #3
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by vgarcia
    I see the data mapper pattern being useful if:

    * You change data stores frequently
    * You have to make your objects work with many data stores at once
    * Your data mapper objects and models are on separate machines.

    If none of these apply, then what's the benefit of data mapper over active record? For example, at work I know we're never going off SQL Server for the lifetime of the apps I'm building. Wouldn't the data mapper pattern just be premature optimization at that point?
    I guess if you know that Active Record suits your requirments, and that those requirments will never change, then it's fine to use it. But if you're uncertain about the future then it could limit your choices in the future.

    Has anyone built a big and/or complicated app using the builtin Active Record support in RoR?
    If so, did using Active Record cause problems later on or did it do well?

    Something I'm also curious about is how does letting the DB schema "bubble up" to the domain logic effect the development process. Has the "bubbling up" effect caused any problems on larger or more
    complicated apps?

    I'm not trying to knock the Rails way of doing things. I've started reading about Ruby(it looks like a neat language) and from the little I've seen and heard about Rails, it looks pretty cool too. I'll probably install RoR sometime soon and start playing around with it.
    I'd just like to see (because RoR is still relatively young) an example of someone who has used Ruby Active
    Records in a big, complicated app(and one where future requirements are not completely certain), and still encourages their use.

  4. #4
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by coo_t2
    I guess if you know that Active Record suits your requirments, and that those requirments will never change, then it's fine to use it. But if you're uncertain about the future then it could limit your choices in the future.
    Again, I consider that premature optimization. If you know or suspect that you'll be changing data stores over the app's lifetime, it's probably best to write it using the "new" data store in the first place. But maybe I'm just not getting it (it happens )

  5. #5
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by vgarcia
    Again, I consider that premature optimization. If you know or suspect that you'll be changing data stores over the app's lifetime, it's probably best to write it using the "new" data store in the first place. But maybe I'm just not getting it (it happens )
    I don't know. I think the word optimization connotes performance concerns, and what I'm concerned more about in this context is flexibility, not peformance.

    Particularly these concerns:

    1. Does using AR tend to "tie you in" more to a particular DB solution(even if you're talking relational DB vs some other type and not just different relational vendor types)?
    2. Does using AR couple your domain logic too closely with your DB design? Does it matter?

    From PoEAA (page 162):

    Another argument against Active Record is the fact that it couples the object design to the database design. This makes it more difficult to refactor either design as a project goes forward.
    Quote Originally Posted by MiiJaySung
    Put it this way, you are more likely going to want to use AR instead of the DM (Datamapper) in most web projects to be honest, mainly for the reason vgarcia pointed out. Bearing in mind that Ruby seems to follow after PHP here with the "shared nothing" idiom, it's less overhead for processing. There are few times when you need to store data in multiple formats or change your data store regularly.
    What about refactoring?

    What about testing?
    I have no experience actually using AR so I don't know if it could actually be problematic - but it does seem like mixing up stuff like this could make testing harder. Is my feeling wrong?


    Quote Originally Posted by MiiJaySung
    The data mapper seems a very over engineered approach for many applications.
    That seems to be true with a lot of Fowleresque patterns. I personally use something similiar(but different) to the DAO found at phppatterns.com. I guess what I use could be considered a severely "dumbed down" version of a data mapper. It has its own disadvantages but I think it does a pretty good job(if you're vigilant) of keeping domain logic and DB design separate. And it's easy to test.

  6. #6
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Put it this way, you are more likely going to want to use AR instead of the DM (Datamapper) in most web projects to be honest, mainly for the reason vgarcia pointed out. Bearing in mind that Ruby seems to follow after PHP here with the "shared nothing" idiom, it's less overhead for processing. There are few times when you need to store data in multiple formats or change your data store regularly.

    If you feel your models are mixing a lot of concerns / concepts (i.e. different types of domain logic) and are getting big, you can break things up so they are in modules, and use include in the model to mix them in.

    The data mapper seems a very over engineered approach for many applications.

  7. #7
    SitePoint Guru
    Join Date
    Aug 2005
    Posts
    986
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And you could always use your own data mapper instead of activerecord, no problem. If you keep the interface the same, you can use the built-in form helpers with your datamapper too.

  8. #8
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by coo_t2
    Particularly these concerns:

    1. Does using AR tend to "tie you in" more to a particular DB solution(even if you're talking relational DB vs some other type and not just different relational vendor types)?
    2. Does using AR couple your domain logic too closely with your DB design? Does it matter?
    1. Rails kind of keeps you in relational databases anyway. I haven't seen it used with many other data sources other than maybe XML. However, you can pretty easily move between databases using Rails's ActiveRecord without modifying much code, unless you added methods where you used database-specific SQL, which is rare because writing SQL at all is rare.
    2. Maybe, but I don't think it matters. Most DB table/model relationships are an exact mapping between table columns and model properties anyway.

    Here's what you need to know about Rails: it was designed to handle 80-90% of the problems of developing webapps. It handles that 80-90% extremely well. If you're an edge case, then Rails may not be the proper platform for you, but why introduce such painful overhead for everyone else who doesn't need it?

    Also, unit testing in Rails is pretty easy, even with the ActiveRecord model. You really focus on the domain logic for testing, since the data connection glue works out of the box 99% of the time (assuming you configured database.yml correctly).

  9. #9
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by vgarcia
    1. Rails kind of keeps you in relational databases anyway. I haven't seen it used with many other data sources other than maybe XML. However, you can pretty easily move between databases using Rails's ActiveRecord without modifying much code, unless you added methods where you used database-specific SQL, which is rare because writing SQL at all is rare.
    I guess if you decide to start using rails then you know that it is relational-DB-centric so I don't
    guess this should ever be a problem.


    Quote Originally Posted by vgarcia
    2. Maybe, but I don't think it matters. Most DB table/model relationships are an exact mapping between table columns and model properties anyway.
    I never liked that approach much although it's probably better in big apps.
    My DAOs don't really do any (rigid)mappings at all. Their main function is to provide an interface to get stuff. Then I instantiate them with a factory so that the exact type and hence implementation is unimportant. Just the interface is important.

    eg. $bookDao->getAuthorsByBookID(1);

    I don't strive for a nice model/table relationship and I don't usually care if a DAO uses more than one table(getAuthorsByBookID would contain a join statement). One of the downsides(and there are several) to that approach though, is that when you make a change in a table it can effect more than one DAO. But my DAOs _tend_ to map nicely to one table, it's just not a rule of mine.
    Another downside of DAOs like the ones I create are that they have a tendency to become modelish themselves. This usually comes as a result of putting business logic in the sql.(which I've done before without even realizing that I was doing it -- and is sometimes unavoidable unless you want to give up some of the power that RDBMS gives you in the first place)


    Quote Originally Posted by vgarcia
    Here's what you need to know about Rails: it was designed to handle 80-90% of the problems of developing webapps. It handles that 80-90% extremely well. If you're an edge case, then Rails may not be the proper platform for you, but why introduce such painful overhead for everyone else who doesn't need it?

    Also, unit testing in Rails is pretty easy, even with the ActiveRecord model. You really focus on the domain logic for testing, since the data connection glue works out of the box 99% of the time (assuming you configured database.yml correctly).


    PS. My intention wasn't to make this a Ruby-specific discussion, but this thread sat in the GDI forum unnoticed so they moved it. PHP frameworks(if I remember correctly) seem to like AR too.

  10. #10
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I know Ruby-specific wasn't your intention, and I'm trying as hard as I can not to make it that. I'm also drawing on my previous experience with writing model objects in PHP and Java. It's just kind of hard given that this thread got moved into the Ruby forum

    Quote Originally Posted by coo_t2
    I never liked that approach much although it's probably better in big apps.
    My DAOs don't really do any (rigid)mappings at all. Their main function is to provide an interface to get stuff. Then I instantiate them with a factory so that the exact type and hence implementation is unimportant. Just the interface is important.

    eg. $bookDao->getAuthorsByBookID(1);

    I don't strive for a nice model/table relationship and I don't usually care if a DAO uses more than one table(getAuthorsByBookID would contain a join statement). One of the downsides(and there are several) to that approach though, is that when you make a change in a table it can effect more than one DAO. But my DAOs _tend_ to map nicely to one table, it's just not a rule of mine.
    Using the Active Record model that's possible too. For example, you can have a model object based on a database view, but that view could be comprised of a 10-table join query. I guess the difference between your implementation and your run of the mill ActiveRecord-derived object is where that join takes place (in the code vs in the database).
    Quote Originally Posted by coo_t2
    Another downside of DAOs like the ones I create are that they have a tendency to become modelish themselves. This usually comes as a result of putting business logic in the sql.(which I've done before without even realizing that I was doing it -- and is sometimes unavoidable unless you want to give up some of the power that RDBMS gives you in the first place)
    I think it's so hard to split what is business logic and data access anyway (doubly so when you get concepts like stored procedures involved), and most of my attempts at doing so in any structured way (i.e. the Data Mapper pattern, which I have tried and found to be kind of a waste of my time) haven't worked out too well. That's from my experience in Java mostly, which is why I find that Rails's ActiveRecord is right up my alley; it fits the way I've grown to think of data/model relationships.

  11. #11
    SitePoint Member
    Join Date
    Jan 2004
    Location
    ohio
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have a headache now. Just like I do after meeting with the product manager

  12. #12
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    When I started this thread I had forgotten that AR support was being built into the upcoming Zend Framework. There was a big brouhaha a couple of weeks ago in the PHP blog world about how some AR code posted by someone in the Zend Framework dev community couldn't actually run on any current version of PHP.
    I wish we had that language-neutral forum or builtin cross-posting ability so the PAD folks could offer their thoughts. Either AR is a really good solution or AR flavored kool-aid just tastes really good.

  13. #13
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by coo_t2
    Either AR is a really good solution or AR flavored kool-aid just tastes really good.
    AR has the benifit of simple mapping, and if you need something more advanced, you can just write normal classes to handle more complex mapping. It means you program in PHP or Ruby, and do database design in your database, rather than trying to do both in XML, which IMO is a good thing.

    Douglas
    Hello World

  14. #14
    SitePoint Zealot
    Join Date
    Nov 2004
    Location
    Yakima WA.
    Posts
    100
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Rails implementation of ActiveRecord is actually very flexible. And there is nothing keeping you from using a mixture of AR and other patterns for your models. I have a rails project that is very very data heavy. It uses 5 different data sources and only one of them is a SQL database. the project is here: http://yakimaherald.com . You can read a write up I did that describes all the various backends here is you are interested:
    http://brainspl.at/articles/2005/11/...kimaherald-com

    Rails has served me very well in the development of this and many other applications I have built. It really hits the sweet spot for most db backed web sites with the AR pattern. but it is written in ruby and ruby is very easy to extend and bend to your will. So I have not run into any areas of my data domain that I couldn't handle with ruby and a little elbow grease.

    -Ezra


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •