Just curious - How cloesly do your value objects back the data model?

[Rick Reumann <ri...@gmail.com>]

I'm often torn when developing web applications how Object Oriented I
should build my value objects. For examle...

You might have an Employee table...

employeeId
employeeName
companyId
//..

Do you guys typically have your Employee value object hold "Integer
companyId" or instead populate the companyId in a Company object as a
property of Employee...

class Employee {
   Integer employeeId;
   Company company; //instead of Integer companyId

I typically take the above approach (using Company) but  there are
times when I don't always follow this practice.

--
Rick

Re: Just curious - How cloesly do your value objects back the data model?

[Rick Reumann <ri...@gmail.com>]

Nevermind my rambling.. I was just being stupid and overthinking
stuff. Company in an Employee makes sense.

On 5/4/06, Rick Reumann <ri...@gmail.com> wrote:
> On 5/4/06, Eric T. Blue <er...@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.
>


--
Rick

Re: Just curious - How cloesly do your value objects back the data model?

[Rick Reumann <ri...@gmail.com>]

On 5/4/06, Eric T. Blue <er...@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.

Re: Just curious - How cloesly do your value objects back the data model?

["Eric T. Blue" <er...@gmail.com>]

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.

On 5/4/06, Rick Reumann <ri...@gmail.com> wrote:
>
> I'm often torn when developing web applications how Object Oriented I
> should build my value objects. For examle...
>
> You might have an Employee table...
>
> employeeId
> employeeName
> companyId
> //..
>
> Do you guys typically have your Employee value object hold "Integer
> companyId" or instead populate the companyId in a Company object as a
> property of Employee...
>
> class Employee {
>    Integer employeeId;
>    Company company; //instead of Integer companyId
>
> I typically take the above approach (using Company) but  there are
> times when I don't always follow this practice.
>
> --
> Rick
>