Comments on Cuberick: To ORM or Not to ORM.

At some point you have to define your database col...

2009-06-13T02:05:50.159-07:00

At some point you have to define your database columns, whether you're sitting at a terminal typing in CREATE TABLE statements, using a UI to configure the table, or specifying the properties in the DataMapper model. I don't see AR's approach more DRY than DM, or vice versa -- the knowledge has to live someplace and it takes roughly the same level of effort to define it in each of those places.

One difference with having it inside the DataMapper model is that you don't have to refer to anywhere else to know what properties your model has.

It also allows things like auto-migrate, in which you can add/remove a property, or adjust a constraint, and regenerate the table quickly from the model snapshot.

Sure once you start deploying to production, you have to write migrations just like AR. Although it is very useful when doing local development to be able to regenerate all the tables quickly in order to test something out.

AR has column names and such in the runtime, you c...

2009-06-04T11:12:52.334-07:00

AR has column names and such in the runtime, you can generate tables from DM. They simply approach it from different directions. I think describing either as more or less DRY is a misuse of the concept (don't repeat Domain Knowledge, ie: Constants or Behaviour).

Sara is mixing concepts. I'd disagree that a Form (which seems to basically be a Controller for her) is a part of your Domain Model. Repository, Presenter, Controller and Domain Model are all different things, and I suppose you might could make a better case for it, but I find the example lacking.

The broader idea that your Domain Model is not your Persistence Layer is a good one I think, but I know of very few O/RMs that are truly mappers for Plain Old X Objects without at least some concessions. At the end of the day, I think it's just not very practical when you have in-memory databases, mocks, stubs, etc at your disposal.

And look, I dislike Relational databases as much as the next guy, but I'll say it now: this JSON/Document/OODB stuff is a fad. You're going to have to spend some real money for real OODB (and it's great, but nothing's perfect, it has it's own issues), and let me know when someone finds a JSON/Document store that can come within 1 order of magnitude of the performance of SQLServer or Oracle on hundreds of millions of rows.

Just because the OSS Databases suck (hey, I like/use Postgres, but price being equal, I'm picking SQLServer every time) doesn't mean RDBMSs are dead, much less inferior. Quite the opposite if the Rails community were to investigate as opposed to rushing from fad to fad to fad ( new deployment stack anyone? :-p ).

So long as the Rails guys fight community against community, so long will they be a little people, a silly people, greedy, barbarous, and cruel... ;-)

Active Record is the poster child for combini...

2009-06-03T23:44:45.951-07:00

Active Record is the poster child for combining ORM with the domain, and in the situation where you have complete control to define and change your DB it is great, though I think it comes at the cost of testability.

That's an interesting comment – could you expand a little on why you think testability suffers when using Active Record?