SitePoint Sponsor |
|
User Tag List
Results 1 to 14 of 14
Hybrid View
-
Jan 28, 2006, 15:18 #1
- 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?
-
Jan 30, 2006, 06:31 #2
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?
-
Jan 30, 2006, 12:34 #3
- Join Date
- Feb 2003
- Location
- Dog Street
- Posts
- 1,819
- Mentioned
- 1 Post(s)
- Tagged
- 1 Thread(s)
Originally Posted by vgarcia
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.
-
Jan 30, 2006, 13:22 #4
Originally Posted by coo_t2
)
-
Jan 30, 2006, 14:13 #5
- Join Date
- Feb 2003
- Location
- Dog Street
- Posts
- 1,819
- Mentioned
- 1 Post(s)
- Tagged
- 1 Thread(s)
Originally Posted by 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?
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.Originally Posted by MiiJaySung
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?
Originally Posted by MiiJaySung
-
Jan 30, 2006, 12:35 #6
- 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.
-
Jan 30, 2006, 13:11 #7
- 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.
-
Jan 30, 2006, 14:23 #8
Originally Posted by coo_t2
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).
-
Jan 30, 2006, 15:32 #9
- Join Date
- Feb 2003
- Location
- Dog Street
- Posts
- 1,819
- Mentioned
- 1 Post(s)
- Tagged
- 1 Thread(s)
Originally Posted by vgarcia
guess this should ever be a problem.
Originally Posted by vgarcia
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)
Originally Posted by vgarcia
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.
-
Jan 30, 2006, 15:44 #10
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
Originally Posted by coo_t2
Originally Posted by coo_t2
-
Jan 31, 2006, 12:26 #11
- 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
-
Feb 2, 2006, 14:18 #12
- 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.
-
Feb 2, 2006, 21:28 #13
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by coo_t2
DouglasHello World
-
Feb 14, 2006, 12:40 #14
- 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