>>> I have a general design question.
>>> When design an OO system that is processing records in a RDBMS
>>> what is the best way to achieve this mapping. For instance, there is
>>> a table in the DB that represents a credit card, the table being
>>> comprised of 50+ fields. What is the best pattern for designing
>>> Credit card object that represents one row from this table?
>>A table with 50+ fields may indicate a bad design in your table structure.
>>For example, people may have several Credit cards, but their addresses and
>>phone number will not change. What you can try is to partition your "fat"
>>table into several relatively smaller objects. I can't see any
>>relationship between the design for this problem related to any known
>The problem at hand (and I should have expressed this in my previous
>post) is that we are dealing with a legacy system. Unfortunately we
>do not have the luxury of changing the file formats.
>I should also state that the database is fairly normalized. Client
>name, address, phone, etc. is maintained in separate tables. Mainly
>this table contains card specific information (card number, expiration
>date, usages information, flags, etc). If anyone has ever dealt with
>credit card processing, you will know that there are many status
>flags, dates, and counters to keep up with.
>I think that there has to be a reasonable way to deal with this issue.
>Maybe the solution is to break the fields down into logical groups and
>express those as separate objects in a container. I'd just like to
>get advise on the subject because we have many objects that map to
>tables that will have this problem.
Sometimes it is hard. Especially with legacy-systems. But it should be
possibly to simplify some things.
Status can often be set from functions internal to the class, so even
if there are a lot of getters and setters (or direct access if you
really want) a lot of those will be private and will only be accessed
via other setters.
Usage information is also only set when other events occur, so those
do not need to be public either. 2 dates sometimes are an interval,
and if intervals are used often it is a very handy abstraction..
Sometimes you can split the table in logical groups. In 1 project we
had a Customer-table and where able to split it up into classes such
as Identity, Address, UnemplomentStatus (a big one!!) and some others.
But I must admit, it wasn't the best database ever designed.