Designing database objects

[afroblanca]

Hello all,

I'm wanting to design a database object that handles most of the gruntwork typically associated with database-driven objects, such as initializing default values, updating the table that the object represents, and retrieving data members from the table.

This object will store all of its data members in an ArrayList (I'm using C#. An equivalent Java analogue would be a Vector) as opposed to having static member variable declarations. The data members in the arraylist will then be accessed through properties (like Java get() and set() accessors).

The main advantage of keeping data members in the ArrayList is that it will allow me to iterate through them programmatically. Using properties to access the data members insures that I will be able to access them in a type-safe way.

Here's my question - is keeping the data members in an ArrayList a Bad Idea? I can see it as adding some overhead (an ArrayList surely uses more resources then a bunch of primitive data types), but I can't imagine that this would be too much of a problem.

How do people usually design data objects, anyway? Do they generally bother to at all? Or do they just have some sort of "utility class" that simply runs stored procedures for them?

 

[chiph]

You might want to investigate one of the O/R persistence frameworks, such as WilsonORMapper or NHibernate.

When using them, you define objects which correspond to your tables (or tables which correspond to your objects!), and then define a XML mapping file which handles the logical translation between them. Reading/Writing data with or without transaction support then becomes very easy.

A good book on Hibernate is "Hibernate in Action" from Manning Press. It's geared towards Java, but all the method calls are pretty much the same for the .NET port, NHibernate.

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[afroblanca]

Thanks for the tip. I think that I've decided to go with a simple model for dealing with the database. Although I like ORM packages like NHibernate, I think that this sort of thing is too heavyweight for my needs.

 

[BobRodes]

IMO, yes, they generally bother, but of course you can go from quite simple to quite complex, depending on your needs.

You might consider structures as a means of storing your data members. Since structures are allocated on the stack instead of the heap, you'll probably have less overhead. Look out for boxing issues, though.

HTH

Bob