RE: [Hibernate-devel] SQL Server 2000 questions

[Anton v. S. <an...@ap...>]

Donnie Hale wrote:
> With that as a background, Hibernate seems to be more aligned with putting
> the data for a row directly in the business object. Many people
> prefer that, and I can sympathize with them. However, it's not
> my preferred approach. I like the data in the DTOs and the
> business objects being focused on the business operations
> that must be fulfilled for a particular type of business
> entity.

What I've been doing (pre-Hibernate) is to have the business objects inherit
from their corresponding DTOs.  This allows the business objects to
implicitly access the data they need, without reference to an external
object.  It also allows you to easily marshal a DTO and send it elsewhere,
without business logic, if you want/need to.  Finally, it handles
relationship issues better, IMO.

This approach ought to work well with Hibernate, and is what I'm pursuing.
But any pattern which maintains DTO-like objects separately from the classes
containing business logic ought to be easier for automated tools to deal
with, especially in early, less-sophisticated incarnations, because it may
allow them to completely recreate the DTOs when the source schema changes.

> All I can say is that I prefer this pattern enough to
> deal w/ relationship management myself at the business object level.

I'm curious what disadvantage you see to the approach I've described.  I
suppose the fact that application objects would inherit a public set of
getters/setters - more than they might need to expose - might be considered
a disadvantage by some.  If that were really an issue, it might be dealt
with by having the DTOs have protected getters/setters, and if the business
objects want to expose any of them, it would define public versions.  Being
able to send independent DTOs elsewhere would then need to be dealt with,
but that could be done too, in a variety of ways.

Anton