|P is for Practical|
OO Perl & RDBMS Strategy Questionby DamnDirtyApe (Curate)
|on Aug 30, 2002 at 02:26 UTC||Need Help??|
DamnDirtyApe has asked for the
wisdom of the Perl Monks concerning the following question:
Mine is a strategy question relating to object-oriented Perl and relational databases.
I'm interested in how people write classes that represent objects in a database, and to what extent operations on an object are mapped onto the database object. The following paragraph from Building a Large-Scale E-commerce site with Apache and mod_perl : Code Structure got me thinking about this again:
Classes in the Model layer represented business concepts and data, like products or users. These had an API but no end-user interface. They knew nothing about HTTP or HTML and could be used in non-web applications, like cron jobs. They talked to the database and other data sources, and managed their own persistence.
I'm curious as to how people actually implement these systems in the real world. As I see it, there are at least two possibilities:
Of course, there may be more ways to do it that I'm just not seeing. How do you do it?
Those who know that they are profound strive for clarity. Those who would like to seem profound to the crowd strive for obscurity. --Friedrich Nietzsche