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.
E.g:
I've got a User class that grabs the user from the database. 99% of the time all I need are the username, password, and first/last name. The other 1%, I'm changing the user's image, or profile (large fields). Loading these last fields can be a drain on resources if I'm just printing out a list of user names, but need to be readily accessible at other times.
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.
Cheers,
James Beninger
In reply to Database Accessor Classes by jbeninger
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |