RE: [Hibernate-devel] SQL Server 2000 questions

[Brad C. <bra...@wo...>]

thanx for the link to martin's work, i will check that out when i can.

we use a layered approach similar to the one u have outlined.  i have
not found that hibernate is more aligned with putting data directly into
the BOs (using terminology below here).  the way we have approached the
architecture is:

DAOs: a mixture of hibernate itself and our own classes (that contain
the queries, so they are not spread all over the application).
DTOs: classes that hibernate maps to
BOs: stateless session ejbs (or just normal classes) that expose the
functions/services of the application.

in our case i c hibernate aligned more with the DTOs.

brad


> -----Original Message-----
> From: Donnie Hale [mailto:do...@ha...]
> Sent: Tuesday, 16 April 2002 11:48 AM
> To: hib...@li...
> Subject: RE: [Hibernate-devel] SQL Server 2000 questions
>=20
<snip/>=20
> Today I started a new project, and I used SQL Server=20
> Enterprise Manager to
> define the schema. I use it because it's very easy, it=20
> provides access to
> all the esoteric things like check constraints, index-based=20
> constraints,
> default values, formulas, etc. Once that's done I can=20
> generate a SQL script
> that will recreate the thing on any database whenever I need=20
> to. I find that
> a much more complete approach. Someone in another message mentioned
> generating the schema from the map and then massaging the=20
> schema w/ the
> db-specific tools. If the schema changes are of any=20
> substance, you'll end up
> dropping the tables and then you have to go back in and re-massage the
> schema. That's why I think the db-specific tools are the best=20
> starting point
> for the in-db schema.
>=20
> >>
> [from Brad Clow, and responding some to others' comments=20
> about instance
> variables and philosophical approach]i agree that writing bean-style
> property methods is tedious, but it is a
> task than can be fairly easily automated.
> <<
>=20
> First, if people haven't seen it yet, check out Martin=20
> Fowler's wonderful
> work at: http://martinfowler.com/isa/index.html. I tend to prefer an
> approach with layers as follows:
>=20
> (database itself) ->
> data access objects (DAOs) ->
> data transfer objects (DTOs) ->
> business domain objects (BOs) ->
> coarse-grained service interface
>=20
> The DAOs have the actual SQL, prepare statements, perform=20
> selects and deal
> w/ result sets, etc. The DTOs (called by many "value=20
> objects", but I'm using
> Fowler's terminology) are Java beans at their most basic - they have
> attributes and setters/getters for each column in the=20
> table/view to which
> they correspond. Business objects have the logic and only=20
> expose operation
> methods, not getters/setters unless absolutely required to=20
> meet business
> logic requirements (think: if it's not in the sequence diagram for the
> business logic implementation, it doesn't get written :). The=20
> BOs  "have-a"
> DTO of the corresponding type to hold the actual data (so it=20
> doesn't have to
> be copied all over the place). DTOs are important, in my=20
> opinion, because
> the values frequently have to be passed "over-the-wire"=20
> between layers, and
> I don't want the business objects being accessible to those=20
> other layers.
>=20
> With that as a background, Hibernate seems to be more aligned=20
> with putting
> the data for a row directly in the business object. Many=20
> people prefer that,
> and I can sympathize with them. However, it's not my=20
> preferred approach. I
> like the data in the DTOs and the business objects being=20
> focused on the
> business operations that must be fulfilled for a particular=20
> type of business
> entity.
>=20
> The good thing is that it should be really easy to generate=20
> DTOs, because
> all that's needed are attributes of the right type and setter/getter
> methods. The only tricky parts would seem to be: construction=20
> based on a
> constructor that takes args (the PK being the way I like it);=20
> and making the
> accessor methods for boolean properties have the "isWhatever"=20
> form versus
> the "getWhatever" or "getIsWhatever".
>=20
> Someone's going to bring up the issue of relationships, and=20
> with the design
> pattern I prefer, it's definitely an issue. The DTOs will=20
> have the foreign
> key for a related table, but not a reference to an instance of the
> related/parent DTO. All I can say is that I prefer this=20
> pattern enough to
> deal w/ relationship management myself at the business object level.
>=20
> FWIW...
>=20
> Donnie
>=20
>=20
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>=20