Doesn't the 'Active Record' pattern suck?

[coo_t2]

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?

[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?

[coo_t2]

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.

[vgarcia]

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 )

[coo_t2]

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.

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?

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.

[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.

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.

[Fenrir2]

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.

[vgarcia]

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).

[coo_t2]

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.

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)

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.

[vgarcia]

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

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).

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.

[jam937]

I have a headache now. Just like I do after meeting with the product manager

[coo_t2]

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.

[DougBTX]

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

[ezmobius1]

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