RE: [Hibernate-devel] SQL Server 2000 questions

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

First - I'm getting double responses from Anton and Gavin. FWIW...

See below.

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

I've been thinking along those lines, except using abstrast base classes for
the BOs which "have-a" DTO and other relationships but which must be
extended for the concrete class. My ideas is to generate the DTO and the
abstract BO and then have the developer write the concrete BO. That way
regeneration can happen at any time w/o the worry of losing custom code that
had been written in the BO. Obviously, if there are substantive changes to
the DTO or abstract BO, then the concrete BO has to change; but it lets the
developer focus on that.

That's how my thinking has refined overnight.

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

FWIW, I wrote a DTO-generator for the project I'm working on today. I'm not
at liberty to share it, unfortunately. Since I can't use Hibernate (SQL
Server 2K support via MS driver isn't complete yet), I wrote my own map file
format. It goes straight from the DB schema (tables or views) to Java DTO
code. I use Jakarta's commons-digester to read the map file and Velocity to
define the .java file template.

My main point is just that I wrote this in a day, so it's not a Herculean
effort.

Summarizing what I personally would like to see:

- a way to make the schema as it is in the database the authoritative
reference of the schema
- a way to generate DTOs from that schema, the DTOs only having a row's
column data - no relationships
- a way to generate the abstract BOs which "have-a" DTO of the corresonding
type along with all the appropriate relationships to other abstract BOs (a
question comes to mind there...), contained/dependent objects, etc.

A side-effect of this concept would be that the .xml file would be used at
generation time as well as runtime.

Take care,

Donnie