How to create business objects against a "wrong" datamodel?

rfcdejong posted on Tuesday, January 13, 2009

Our datamodel is very restricted as it isn't using the normal forms, i bump into problems designing my business objects because they must know how to go back into the database, some keys must be available (as a private property)

We have the following tables:

Person Personadres
I was thinking about a Person business object and an adres business object. The Person business object with public factory methods. And the adres business object without any factory method.

Then an PersonAdresList containing an PersonAdres businessobject with a specific role for the adres.

The real problem is that we need to continue on this "wrong" datamodel with ALOT more combined primairy keys. Reading the book i found nothing about this

rfcdejong replied on Tuesday, January 13, 2009

Btw.. we don't have 'usecases', i must make them myself.

Some adres (Address) roles are 'livingadres', 'postadres', 'old adres', 'business adres', 'future adres', etc..

And yes... double records in the database, resulting into multiple adresses.


The question is more:

Is it smart to split up the business objects as i was thinking in this topic? Normally an address could be assigned to multiple persons, but in our datamodel it can't..

Or just place the 2 common roles as properties in the person object?
Or just make 2 childs for the 2 common roles and a 3rd child for the other roles.

SonOfPirate replied on Wednesday, January 14, 2009

Remember that your business objects are modeling behavior.  The data model that you use should not be a controlling factor.

I think you are on the right track.  If it were me, I would have a Person class (BusinessBase) with an Addresses property of type PersonAddressList (BusinessListBase) which contains my PersonAddress (BusinessBase) objects.  Each PersonAddress contains the address information as well as the role.

The PersonAddress class would be a child object, so you'd override all of the applicable Child_XYZ methods, etc.  Your Person class would be the root/parent.

If your Roles are defined in a list somewhere else, then this doesn't change.  You'll simply have your Role property in the PersonAddress class reference the appropriate primary key in your Roles table (or whatever).  A separate RoleList class is used to load the values and bind your UI controls.

Hope that helps...

rfcdejong replied on Friday, January 16, 2009

It's just the information which'll be needed when going back into the database. Primairy key fields, combined or not, are just important information.

And we are using the ObjectFactory model which make things more complicated :)

TerryCincy replied on Tuesday, January 25, 2011

Completely agree.  Business objects define "BUSINESS" tangibles (that should be identifiable by non-techies),

and do not innately relate to database design.  It's a very common misunderstanding.   So if your data model or current database

is flawed, now is a great time to analyze business processes and their objects.  Then go back and

clean up and normalize the data.

 

All the best .....