Advice on object structure

[Paul]

Hi all,

A journal system I'm building requires there to be the functionality
of the user being able to choose any of a number of extra input field
options in their preferences. These input field options enable extra
fields on the journal input screen (they could be anything from
checkbox lists, to text boxes etc).
I've implemented this by making each of these extra fields a class
which takes care of their own loading, saving, populating of data on
the page etc. This happens by checking the user's preferences, then
loading the selected objects into a List<T>. Each of these objects/
classes utilises a interface so sae load etc can be called on them by
looping through the List<T>.
I'm slightly concerned that the method I've implemented might make
too many DB calls, the main journal will make one call, then each
created object will make 1 db call. With connection pooling, should I
be worried about this? For example, if a user has 9 objects loaded,
and 10 people view that journal, that will be 100 db calls to display
the page for all 10.
An alternative solution to this (but less elegant) is to append new
control fields to the journal table and then have a large class which
fetches everything in 1 call, and lots of code to separate it all
out. This deviates slightly from OOP but cuts down the amount of
times the DB is called.

I'm really looking for opinions on which of the above methods would be
best, and should I be concerned at each object calling the db
separately as hey initialise/save themselves?

 

[Paul]

Hey,

if this is the wrong place to post such questions, i'd very much
appreciate it if someone could point me to a more appropriate
newsgroup. Before the system goes live, i'd like to make it as robust
as I possibly can.

Thanks,

Paul

 

[John Saunders]

....

I'm really looking for opinions on which of the above methods would be
best, and should I be concerned at each object calling the db
separately as hey initialise/save themselves?

My advice would be to get it working first, then to worry about performance.
For all you know now, the number of database calls may not be your biggest
problem. It could be the amount of memory used, or something else.

Or, your biggest problem could be that your program doesn't work. In that
case, the performance issue will be moot.

John