Re^3: Class::DBI not intuitive

A more complex tool (or possibly custom written code) could use a longer more complex query with multiple table joins to return a result set which can then be mapped into an object. So now your class-fields map to columns in multiple tables.

This may be a dumb question, but how is this different from the business object mapping that I referred to?

The benefits of CDBI and similar tools (like Hibernate for Java) is that they do a lot of work for you, but the tradeoff is that the work is generally mediocre. In the places where mediocre is good enough, then it would be foolish to do that work by hand. (The other app in my office uses Hibernate, specifically for that reason.)

But, in those places where you need to write custom code to map your objects (which are presumably business-oriented) to the database (which is presumably storage-oriented), you don't have an OO->Relational tools gain.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re^3: Class::DBI not intuitive

Replies are listed 'Best First'.
Re^4: Class::DBI not intuitive by stvn (Monsignor) on Jul 29, 2004 at 17:16 UTC
This may be a dumb question, but how is this different from the business object mapping that I referred to? It may not really be that different. It all depends upon how you go about it. Our internal OO->relational system uses 2 classes for each object. One is the class which fetches/updates/inserts data into the DB. The other is the object (business object) we use in the application. The only thing these two objects need to share is a common set of attributes (object fields, and table columns (or multiple table columns)). The main heart of the system is a mediator object which handles the interaction of these 2 classes. The result is that while we don't get as much for free as you might from something like Class::DBI, with a little more up front work, you can reap many more benefits. The result is that easy things are a little harder than normal, medium things are not much harder than easy things, and complex things are reasonably proportional to their own complexity. From what I have seen with many OO->Relational mappers, the complexity of the implementation rises at a much faster rate than the complexity of the problem itself, and so they can quickly become more of a burdon then an asset. Now, of course, our system is not perfect, it has its flaws, in particular its very inefficient with large tables (many columns, not many rows). And it cannot automagically handle joins, you have to hand-code the SQL (although it can handle foreign key/link relationships as lazily loaded objects). It is also still pretty much specific to much of the database work we do, so it doesn't handle BLOBs (although it could be made to quite easily, we have just never had a need), and it has only really be tested on MySQL and PostgreSQL. Some tools may require more custom code than others, but sometimes that extra up-front work is worth it, if you can get some other things for free. I guess my point is that the tools dont always have to be inefficient, and it doesn't have to be an all or nothing deal. -stvn	[reply]

Replies are listed 'Best First'.

Re^4: Class::DBI not intuitive
by stvn (Monsignor) on Jul 29, 2004 at 17:16 UTC

This may be a dumb question, but how is this different from the business object mapping that I referred to?

It may not really be that different. It all depends upon how you go about it.

Our internal OO->relational system uses 2 classes for each object. One is the class which fetches/updates/inserts data into the DB. The other is the object (business object) we use in the application. The only thing these two objects need to share is a common set of attributes (object fields, and table columns (or multiple table columns)). The main heart of the system is a mediator object which handles the interaction of these 2 classes. The result is that while we don't get as much for free as you might from something like Class::DBI, with a little more up front work, you can reap many more benefits. The result is that easy things are a little harder than normal, medium things are not much harder than easy things, and complex things are reasonably proportional to their own complexity. From what I have seen with many OO->Relational mappers, the complexity of the implementation rises at a much faster rate than the complexity of the problem itself, and so they can quickly become more of a burdon then an asset.

Now, of course, our system is not perfect, it has its flaws, in particular its very inefficient with large tables (many columns, not many rows). And it cannot automagically handle joins, you have to hand-code the SQL (although it can handle foreign key/link relationships as lazily loaded objects). It is also still pretty much specific to much of the database work we do, so it doesn't handle BLOBs (although it could be made to quite easily, we have just never had a need), and it has only really be tested on MySQL and PostgreSQL.

Some tools may require more custom code than others, but sometimes that extra up-front work is worth it, if you can get some other things for free. I guess my point is that the tools dont always have to be inefficient, and it doesn't have to be an all or nothing deal.

-stvn

[reply]