Architecture Advice - Relational vs Behavioural

REA_ANDREW posted on Tuesday, April 01, 2008

Please could I have some views on the following.

Is it efficient to create a normalized database. Then create Views for the interaction with the business library. This way I am creating an efficient normalized database, whilst persisting a behavioural object orientated design by the use of views for the creation of the objects, and other stored procedures for the INSERT, UPDATE, and relational cascade rules for the DELETE.

OR, should I scrap the normalized database design, and go for an object orientated design where each table models the object and foreign keys are used where collaboration exists, and ultimately causing duplicate data.

Thanks for your time,

Andrew

ajj3085 replied on Tuesday, April 01, 2008

When doing database design, you should follow good database design guidelines. It's ok if the database doesn't match your business object models; part of the job of the BO is to know where to get its data.

REA_ANDREW replied on Tuesday, April 01, 2008

In the book Expert C# 2005 Business Objects Second Edition, Page 50, Paragraph 3 & 4

It says that we may have two objects, Customer and Invoice where both deal with Customer Data. It says that it is a naive approach for the Invoice to make use of the Customer object, as it should only be used:

"in the case where the application is adding or editing customer data"

I agree, BUT what it does not discuss is the possibility that the Invoice object could make use of the CustomerInfo object which is read only, and thus resuing code. Is this going against Encapsulation and if so, should I redfine the fields and properties in the Invoice class itself or create another class called maybe InvoiceCustomerData.

Thanks again,

Andrew

ajj3085 replied on Tuesday, April 01, 2008

Um, I personally use that method as well. The Invoice object has a SetSoldTo which takes a ContactInfo object and copies the data into it. I also store the key so that users can refresh the contact information, since the invoice's sold to data is seperate from the contacts (for history reasons).

Rocky usually recommends desiging objects to satsifiy all your use cases. Don't re-use anything at this point. Then when your design is done, go through and identify if any objects can be shared. But the criteria is that the type's behavior must be identical in any use cases which are sharing the type.

HTH
Andy