business object modeling

[mark.oliveira]

Hi,

I was hoping somebody can help me with a design question. I have read
in numerous places that business objects should not even know that a
database exists let alone know about how the object itself is
represented in the database. My question is, how do you keep track of,
say, properties that are stored in the database as key/value pairs?
The object cares only about the value but the key is also necessary for
when u want to store the data. For example let's say I have a shape
table and one of the columns is color_id. Then assume there is a color
table with id and name as columns. How do I avoid having a "shape"
business object with both properties, colorId and colorName? Is
including the id considered "bad design"? Any insight would be much
appreciated.

Thanks!

Mark

 

[VisionSet]

Hi,

I was hoping somebody can help me with a design question. I have read
in numerous places that business objects should not even know that a
database exists let alone know about how the object itself is
represented in the database. My question is, how do you keep track of,
say, properties that are stored in the database as key/value pairs?
The object cares only about the value but the key is also necessary for
when u want to store the data. For example let's say I have a shape
table and one of the columns is color_id. Then assume there is a color
table with id and name as columns. How do I avoid having a "shape"
business object with both properties, colorId and colorName? Is
including the id considered "bad design"? Any insight would be much
appreciated.

colorId doesn't have any relevance in object space, it is just there to
perform relational algebra. What your interested in is the colour itself and
that is what should be an attribute of your shape object.
When it comes to persistence in a relational DB, you use some form of DAO
that does all the mapping between the relational and object worlds.
This DAO tier knows the SQL to do the joins and create the objects, then the
tiers either side DB & BOM are blissfully unaware of each other.

 

[tom fredriksen]

Hi,

I was hoping somebody can help me with a design question. I have read
in numerous places that business objects should not even know that a
database exists let alone know about how the object itself is
represented in the database. My question is, how do you keep track of,
say, properties that are stored in the database as key/value pairs?
The object cares only about the value but the key is also necessary for
when u want to store the data. For example let's say I have a shape
table and one of the columns is color_id. Then assume there is a color
table with id and name as columns. How do I avoid having a "shape"
business object with both properties, colorId and colorName? Is
including the id considered "bad design"? Any insight would be much
appreciated.

What would be normal in such a circumstance is to have a persistence or
storage tier below the business tier with a mapping independent
interface. The interface would only care about what kind of operations
are desired and how to pass the required information back and forth.

The implementation of that interface must be able to map the information
from an internal format to the storage format and back. Thus making the
storage format completely independent of the internal format. That means
that any requirements of the storage format must be dealt with by it
self and nobody else. I.e. color_id is only used to describe a primary
key in the table, it must still have a color name which you use in the
application.

The information sent across the interface should be transferred in
either a dao (data access object) or a dto (data transfer object). A dto
is more a placeholder for information in transit, so the business tier
and the storage tier must convert its own represenations to a dto before
communicating it to the other part. A dao is perhaps a bit more
integrated and the business tier communicates with the dao directly to
retrieve storage data in its own format directly.

Whether to use a dao or a dto is an architectural desicion. A dao can be
more tightly coupled, allthough it can be loosened up a bit by using the
strategy pattern. The dto has very loose coupling, more to the style of
server/client, since both parties must have their own interpretation code.

Hope that helps

/tom

 

[James McGill]

Hi,

I was hoping somebody can help me with a design question. I have read
in numerous places that business objects should not even know that a
database exists let alone know about how the object itself is
represented in the database.

I use Hibernate for this. I let the app server manage connections and
the hibernate session factory, and the app just deals with the data as
though they are persistent objects. The only representation used, is a
java object, and all the database stuff decoupled.

 

[mark.oliveira]

Thanks for the responses.

I actually do have a data access layer which utilizes DAOs and
communicates with the model via multiple DTOs. The problem is that it
seems like alot of overhead to be constantly looking up the id for a
color name when I want to simply insert the color_id in the database.
Also, it is less expensive to compare color_ids than color_names. What
I have been doing is just storing the color_id in the business object
but that somehow seems innappropriate. For example, what if I had a
dropdown list of color names, I would want the key to be the id in the
database, and the value to be the name shown. How would I do this if
my business objects aren't allowed to know about ids?

 

[tom fredriksen]

Thanks for the responses.

I actually do have a data access layer which utilizes DAOs and
communicates with the model via multiple DTOs. The problem is that it
seems like alot of overhead to be constantly looking up the id for a
color name when I want to simply insert the color_id in the database.

Thats the point, you dont want to insert a color_id into the database,
you want to add a colour to something.

For example (here is what you wrote earlier):

The object cares only about the value but the key is also necessary
for when u want to store the data.
For example let's say I have a shape
table and one of the columns is color_id. Then assume there is a color
table with id and name as columns.

No. Above the storage tier you only care about the colours, Its the
storage tiers responsibility to find the correct id for the colour, as
the tiers above know nothing about its representation of the data model.
So you have a shape that has a colour, thats what you tell the storage
tier: dto-"store this shape with that colour" and the storage tier has
to figure out how to represent that in its own data model.

Also, it is less expensive to compare color_ids than color_names.

Usually this is done in a stored procedure in the db, so it would look
up any primary keys you need, and construct the final insert. Also using
proper indexes in the database a colour_name -> id lookup is only adds a
fraction of time to doing the insert.

It can of course be made more efficient, as you say, by you just using
the colour_ids directly. That requires you to keep a mapping between the
representation of the db colour_id value and the programs colour_id
value (which makes it slower again). The point is to try to decouple the
semantics of each tiers internal values from each other so as to make it
easy for you to change one or the other without making too much problems
for yourself. Thats the point of a dto.

Its all a compromise, but the ideal situation is to try to devise a data
model at the storage layer that is as efficient as possible and at the
same time is as decoupled as possible.

Hope I did not explain that too badly

/tom

 

[James McGill]

To avoid using a PK for philosophical reasons, can incur a significant
cost in practical terms. Queries that use a PK tend to be much more
efficient than queries that iterate through a rowset or that search
based on criteria other than a key.

 

[tom fredriksen]

To avoid using a PK for philosophical reasons, can incur a significant
cost in practical terms. Queries that use a PK tend to be much more
efficient than queries that iterate through a rowset or that search
based on criteria other than a key.

Sorry, I don t quite understand how this relates to the discussion at
hand. AFAICT, nobody has stated that one should avoid using a primary
key. Could you please elaborate.

/tom

 

[mark.oliveira]

Thanks for the reply.

I understand what you are saying. Do you think I should then have
something like color = "blue" in my business object and then have a
mapping table or something along those lines which allows me to provide
"blue" as a parameter to my database insert? I still somehow feel less
confident about passing around Strings than ints, but maybe that is
paranoia.

 

[tom fredriksen]

Thanks for the reply.

I understand what you are saying. Do you think I should then have
something like color = "blue" in my business object and then have a
mapping table or something along those lines which allows me to provide
"blue" as a parameter to my database insert? I still somehow feel less
confident about passing around Strings than ints, but maybe that is
paranoia.

Yes, a mapping is usually a good idea, though it does not need to be a
table. A mapping would give you a separation of the internal values in
each tier, that allows you to choose the most efficient and proper
internal representation for each tier.

I would perhaps suggest an enum version, ie. with an enum constructor
and getString() method, but that requires that you define the colours
beforehand.

/tom