RE: [Hibernate-devel] SQL Server 2000 questions

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

Donnie,

Thanks for the feedback, it's helping me clarify my thinking on this.

> 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.

How about this: define business object interfaces which your business
objects implement.  Clients of the business objects use these interfaces.
This would prevent clients from having access to DTO property methods
through the business objects, except by violating protocol and bypassing the
interfaces.

Using interfaces like this clearly documents and helps enforce which aspects
of the business objects are supposed to be public, which achieves the aspect
of this that I find most important.  But if you're set on actually enforcing
restrictions on getter/setter access through the business objects, you could
discourage or prevent such violations by appropriate use of factories for
the business objects, and protected constructors.

> 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.

I agree, and I was saying something along these lines in a reply to Gavin
last night.  I'm impressed by what I've seen so far.

> 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... :)

Given Hibernate's use of getters/setters to populate the data, I don't see
why something pretty close to this couldn't be done fairly easily.  Here's
an outline:

First, use the approach I described above, with DTOs being parents of the
business objects, with public getters/setters.  Use interfaces for the BOs
if you want to control and better document access to the getters/setters.

Now, have Hibernate populate and persist the data via the BOs, not via the
DTOs.  Hibernate should use the getter/setter methods it's told about,
whether they're defined in the BO or inherited from its parent, the DTO.
This ought to allow you to split the basic instance/row data from the
relationships, exactly the way you want.

You ought to be able to hand-write a system right now that used Hibernate
like this, so Hibernate itself wouldn't need to change a bit - once again
demonstrating the power of a well-designed "lightweight" layer.  To make
this a bit more automatic, the schema management tools we've been talking
about could generate and later update the appropriate classes, although that
would go beyond the level of sophistication I was personally planning to get
into.  Still, I'll keep it in mind, since I'm working on some of this kind
of thing right now...

Anton