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

> Applications are generally independent of each other (altough they
> often communicate indirectly through the DB).

Unless you use reusable domain objects. Lets say we have a customer table, does every application has its own customer class?

> Changes to applications
> have much to do with behavior and formatting, and not so much to do
> with data.

If we change the data, lets say we add a new column, phoneno, to the customer table, doesn't the application need to change?

> Since the forces that change databases and applications are different,
> and their customers are different, they should be designed for these
> different environments and constraints.

What are the forces to change databases that would not also force you to change the application?

> If an application depends strongly on the database structure, then the
> structure of its behaviors will be coupled to the database structure.
> Since this structure is a result of catering to many different
> applications, each application will have an indirect coupling on all
> the others.

I am not sure about your definition of "application". But in many cases there are only one application using a databases or multiple applications that all share common domain objects, that will couple that together anyway.

> Or to say this a different way, the application will not
> be able to use the data structures that are most favorable to its
> algorithms because it is coupled to the DB whose data structures are a
> compromise between all applications.

Using views maybe?

> If, on the other hand, the applications are designed to be independent
> of the database structure, then the applications can use whatever data
> structures are appropriate for their algorithms.

A algorithm could must obviously know about the data structure.

Fredrik Bertilsson
http://moonbird.sourceforge.net Received on Tue Jun 13 2006 - 08:08:35 CDT