Re: OOP Confusion

[CountZero]

I suggest you take a look at DBIx::Class and the philosophy used there.

In a OO-database object, you should generally avoid to store the data itself (unless you want to implement some caching system) as data is ephemeral. The object generally should represent a certain table or query, with methods e.g. that give you a row-object and methods of the row-object that give you access to the fields and its data.

Mind you, this is not something for the faint-hearted and pitfalls abound.

Personally I like DBIx::Class a lot, but there are other similar solutions which all do more or less the same in a slightly different way: Rose::DB is one module that springs to mind. SQL::DB is also an object-oriented database module but with a more "close to the metal" feel, yet not as basic as the venerable DBI.

[sundialsvc4]

Whereas I, always the contrarian, do not find it to be particularly useful.   I really don’t need a tool to write the SQL for me, especially since the SQL in an application, once written, rarely if ever changes.   (The notion that “you can just change the schema and you won’t have to change your code!” is something that has never worked-out for me in real life, since substantial database changes, when they occur, always precipitate deeper changes in logic.)   This is just me, and my opinion won’t buy you a cup of tea.

Also, I would want my “data acess objects” to completely conceal the existence of the database from all their clients ... not merely to provide, as it were, a database-API for them to use.   More than one of my data-access objects might well wind up interacting with the same database table or tables, should the implementation of the “application data ‘thing’” happen to wind up that way.   But, once again, just me, no tea.

So, who’s “right, wrong?”   No such luck.   There’s more than one way to do it.™   The design has to be clean and maintainable, for a very long time.   And, I think, it should always have a boots-on the-ground reason that is not merely philosophical ... that is very firmly grounded in your application at its present state.   Whatever you wind up with, it should visibly make your application easier to design and to maintain, and it should neatly encapsulate a fair amount of its complexity.   It will need to work easily alongside whatever older code the app already contains, without forcing itself upon the older code in order for either one of them to [continue to] work properly.   If you have an existing app with a substantial amount of database work already in place, seriously consider not trying to make it “–er” by introducing another different way to do the same thing.   In the end, it’s all an engineering judgment-call.

[CountZero]

I'll tell you my experience. I have a large database (close to 700 000 records now) and the design remained as good as unchanged over more than a decade. I have set up all the usual DBIx::Class classes and getting the info I need out of the database and into LaTeX, Excel, R, ... is so easy with all the standard methods of DBIx::Class applied to my classes. I don't even have to enter passwords and such. Chaining its objects (in other words apply an SQL query to the result of a previous SQL-query) is a real time-saver. For hundreds of "one off" scripts, the boilerplate to connect, set-up, select and loop through the query results almost entirely disappears.

And once you have to work with many-to-many relationships, you will really appreciate all the convenience DBIx::Class gives you.