ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Reumann" <ric...@gmail.com>
Subject Re: Just curious - How cloesly do your value objects back the data model?
Date Thu, 04 May 2006 19:39:51 GMT
On 5/4/06, Eric T. Blue <ericblue76@gmail.com> wrote:
> Typically, you would/should not expose properties that are used in deriving
> a database relationship.  These type of id properties are called surrogate
> keys and do not have any real business meaning.  I'd recommend modeling your
> objects as Employee -> Company, and let SQL do your joins on the id
> columns/properties.

Are you saying you wouldn't even include a Company object inside of an
Employee? If so, I do see your point and often feel/felt the same way
- but the problem then comes with making things clean in your web
application. I understand about separation of concerns, but let's take
an example...

You have a screen that lets an administrator modify employee data
including assigning the employee to a different company. In the most
basic of uses you'd be capturing employee data (name, address, etc)
but you also need to pass along a companyId to assign the Employee to.
 How do you suggest getting this to the backend? Would you pass it all
in a  Map (ala Vic style:),  would you pass a Map that has an
EmloyeeVO and a companyID in the Map? Do you see what I'm getting at?
I understand these surrogate keys don't have any true business meaning
and that bothers me, yet in the application ibatis ultimately needs to
get this data somehow in a way that isn't cumbersome.

Also lets take the separation of concerns a step further.. typically I
have a Service layer that gets called that does the dao call.. so for
example...

SomeService {
    updateEmloyee(Employee employee) {
       dao.update(...., employee );

So now how would you pass it the companyId that is also needed (if
Employee isn't going to hold companyId)?

updateEmployee(Employee employee, Integer companyId ) ???

I'm not sure I like this approach since think if business rules change
and maybe not only companyId  needs to be supplied, but also maybe
something like a departmentId - now instead of just modifying the one
"Employee" object you have to refactor your update signature and all
the classes that may call it.

Going the other way on retrieval you run into similar problems. If
someone is going to edit an Employee including the company they belong
to, you need to retrieve this Employee. If you want to return a map
things are ok since you can shove companyId and other company
Information in there along with the employee information. But what if
you wanted to use a POJO? What kind of pojo would you use? Would it
not have to contain some kind of handle to at least a companyId?

All of this is quite frustrating, because from an OO perspective it
doesn't really fit to have a Company object as a property of an
Employee since it's really the other way around - Companies have
employees... Employees aren't really the true parent of a Company.

Mime
View raw message