Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

> > Both schema and application changes all the time (called versions). But
> > as long as you can not produce one single resonable example of a schema
> > change that will not change any part of the application outside the
> > "persistence" layer, it is a little bit difficult to understand why I
> > should partion my application from the SQL statements.
>
> Adding the birthdate column to an employee record should have no effect
> on the modules that calculate his pay.

Adding a new column will not break any existing SQL statements. In what what way do you mean that a coupled strategy will fail by adding a new column?

However, if you are planning to use the column you added, you need to change the interface to the "persistence" layer. Your business logic (and most likely the prestentation layer) need the birthdate to do what it is supposed to do with it.

In fact, adding a birthday column is much harder using a "persistence" layer. First you need to change your domain object (or value object). Then you need to change all select statements to select the new column and populate the new domain property. The update and insert statements has to be changed too.

Your example failed badly, please give me another one.

Fredrik Bertilsson
http://frebe.php0h.com Received on Wed Jun 21 2006 - 00:19:09 CEST