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:53:53 GMT
Nevermind my rambling.. I was just being stupid and overthinking
stuff. Company in an Employee makes sense.

On 5/4/06, Rick Reumann <rickcr@gmail.com> wrote:
> 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.


View raw message