Accessors for member variables turn objects into glorified structs. When you design an object's interface, it really should be in terms of messages, not in terms of what guts the object contains.

SImilarly, ORMs map each column into the interface, instead of mapping the interface from the use cases. Surely, you could create "actual" objects that encapsulate that, but I don't see that happening very often (even in my own code).

What happens when the DBA decides that street address should actually be two fields: street number plus street name? We now have to ripple that through all the code, because all the code was talking directly to the street address text field before. Sure, we can do some wrappers and things, but a proper OO design would have minimized the locality of that knowledge. ORMs don't encourage that design.

I'm actually working on actual objects which encapsulate that, but I made the mistake of inheriting instead of delegating, thus exposing too much. I have a robust enough test suite that the refactoring should be easy, but I'm kicking myself for being so stupid.

Of course, if one has a poorly designed database, making this distinction is even more important.

Cheers,
Ovid

New address of my CGI Course.

The obvious: I would think twice if I should use an ORM when performance is REALLY critical. Maybe some tutorials on how to profile queries and improve the performance would be nice. In my (humble) experience, this isn't that trivial...

A decently fast ORM like Rose::DB::Object probably wouldn't be noticable for most of the accesses. For the critical ones, you could push the queries down directly as handwritten SQL using the same database handle, so RDBO gets out of the way when you need it (as do other ORMs).

-- Randal L. Schwartz, Perl hacker

merlyn is right. Rose is wicked fast. It's fast enough that you're unlikely to notice too much of a difference and it's easy to fine-tune, if needed. The wins with Rose (and its clean design), easily outweigh the losses.

You can see the benchmarks for yourself.

Cheers,
Ovid

New address of my CGI Course.

When you work with many tables and gigabytes of data, you have to fine-tune many queries. The last time I had these problems, this tuning was not that easy because an ORM is kind of a blackbox - RDO probably less than others. I ended up with ugly code that was not more maintainable than plain DBI code. Well, probably I am someone who does silly things with ORMs ;)

But I really like RDO, so I'd interested in reading more about things you should consider (probably starting with the db schema) when you go beyond little webapp databases ;)

On a similar note, if you're storing serious amounts of data you can't (unfortunately) ignore the fact that relational data modeling and functional object modelling are unfortunately not the same. Your database model may not exactly match your object model. Here you again need a flexible ORM, you need to design your object and relational model side by side and be willing to make compromises in both where it makes sense. Lazy object population can also be your friend here when you have particularly costly database retrieval.