|There's more than one way to do things|
Database Accessor Classesby jbeninger (Monk)
|on Mar 06, 2006 at 16:38 UTC||Need Help??|
jbeninger has asked for the
wisdom of the Perl Monks concerning the following question:
Great and Almighty Perl Monks, hear my plea.
I'm designing my billionth (approximate) web app, and have finally decided to use a philosophy other than "willy-nilly" for my data objects. I was hoping one of the bright minds here may be able to point me in the direction of some good design patterns, philosophies, articles, or google search terms to help me out.
The problem in a nutshell: What's the best way to make an efficient database accessor class? You know - one that's generic enough that it can be reused, but specific enough that it's not writing entire 1M binary fields on every set...() call. And one that's well-encapsulated, so if I hand it to a coworker, they'll be able to make an educated guess as to when the database read/writes are actually happening.
How does your design philosophy say I should treat this, so I'm only loading the large fields when they're required?
I figure this has got to be a very common problem, and have a number of homegrown solutions. With such a large group of experts at my fingertips, though, I'm sure there are solutions out there that put mine to shame. Any links you could provide would be greatly appreciated.