RE: [Hibernate-devel] SQL Server 2000 questions

[Donnie H. <do...@ha...>]

Anton,

You know, I should have considered that approach. Another developer just
recently used something quite similar on a project I was on - full-blown
business objects, which had relationships and logic, were derived from
"summary" objects which had the data. He found it worked quite well, and
it's something I should have recalled. The only downside to that approach is
that, for the DTOs to be useful on the other side of the wire, the
setters/getters have to be public. Which means that they're public on the
business object as well, and I don't really like that. Too procedural, not
good for abstraction and encapsulation.

What I meant to put in my prior message but forgot is that a lot of the
tools along these lines try to be all things to all people. That's
commendable, but it also makes some of them unapproachable. I'd much prefer
a tool that enforced "best practices" for design patterns (especially if
they're the best practices I agree with ;); and I think Hibernate has a
chance to do that or at least get close by being fairly thin and
lightweight. At present it's still pretty approachable.

What would be nice with your pattern is if Hibernate allowed you to define
and use the DTOs for just row data but to generate the relationships at the
business object level. That would get very close to what I like. A business
object "is-a" DTO; it has references to other BOs or sets of BOs to which it
is related; it has instances of DTOs which are dependent objects (no
corresponding BO). Appropriate references to typesafe enum instances for
codes and simple lookup values. Then I'd be done... :)

Take care,

Donnie


> -----Original Message-----
> From: Anton van Straaten [mailto:an...@ap...]
> Sent: Monday, April 15, 2002 10:36 PM
> To: Donnie Hale; hib...@li...
> Subject: RE: [Hibernate-devel] SQL Server 2000 questions
>
>
> 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
>
>