Re: constructing dynamic class definitions at compile time (from schema definition)

broquaint's answer is right, but I want to address a problem with your question.

You're creating classes to represent tables, in a 1-1 relationship. I'm trying to figure out why.

Wouldn't it be better to create classes that represent logical concepts in your business logic? Then, go ahead and create tables that represent the fully normalized way to store any data needed for those classes to work. Within the class, you map between the logical and structural.

My gripe is because this seems to be a knee-jerk reaction, especially in systems where the applications developer is also the DBA (or, at least, plays one on TV). This results in extremely unmaintainable code. For example, what if your schema changes? Your entire application code now has to change. (This is called "tight coupling".)

Better is to do what I suggested, and let your schema and application change independent of each other. The only coupling you have is in the guts of your classes. (This is called "loose coupling".)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re: constructing dynamic class definitions at compile time (from schema definition)

Replies are listed 'Best First'.
Re: Re: constructing dynamic class definitions at compile time (from schema definition) by sozinsky (Initiate) on Jul 25, 2002 at 16:21 UTC
Actually , its tight coupling that I'm trying to avoid. The business problem is this: I'm loading a bunch of data into a database via the .bcp mechanism. The data is loaded into a "raw" table, and from there I sql over the raw table and insert into a more 'refined' version of the table. To represent this, I have a RawTable class, whose attributes are the columns of the corresponding raw table. Every time I add / remove a column, I have to change the class definition of the RawTable ( too tightly coupled ). If the class builds its definition from the raw table schema, then I never have to change the RawTable class; it picks up the changes automatically. Thus, if the schema changes (ie remove/add a column), exactly the _reverse_ happens to what you described above: I have to change _no_ code. Thus in this case, I don't have to worry about the schema and application being too closely coupled; this close coupling is actually a Good Thing. Granted, for larger problems, all of your points above are quite valid.	[reply]
Re3: constructing dynamic class definitions at compile time (from schema definition) by dragonchild (Archbishop) on Jul 25, 2002 at 18:48 UTC
Fair enough. However, I would still say that you shouldn't dynamically generate a class from a table. Let's say that a column does change in your RawTable. The corresponding API of the RawTable class changes. How are the clients of that class supposed to know that the API has changed? What if it's a column that disappears? Your API contract is now invalid. Not good. ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply]