Re: [Springframework-developer] Petclinic updated

[Rod J. <rod...@in...>]

> I question why you would make this change?  I understand (and like) the
Hsql
> and MySql implementations since they show the core of what Spring allows
(that
> you can make specific implementations where required).  However, you are
> coupling the implementation of clinic with the dao interface and the jdbc
dao
> implementation.  I may be missing something, but isn't this a step
backwards?
> In my mind, the implementation of Clinic should be seperate from its
storage
> mechansim (ClinicDAO), and the DAO would be an interface which is then
> implemented (in this case by the above mentioned AbstractJDBC and then the
2
> db-specific implementations.  To quote Rod's book "sometimes we are unable
to
> seperate the two (business logic and persistence logic)" but I don't see
this
> as one of those exceptions.  While I personally hate EJB, this new design
> totally excludes it (since there is no clinic object unless you use JDBC),
but
> it also would exclude other persistence mechanisms (xml, flat-file, etc.)
or
> even using an "unpersisted" version of the clinic (unless you choose to
carry
> around all the JDBC stuff as baggage which adds 13 RdbmsOperation
objects).

Without going into the specifics, which I don't have time to think about
right now, I should say that I've changed my opinions somewhat since the
book regarding separating persistence & business logic.

Where transparent persistence mechanisms such as JDO or Hibernate are
concerned, I think there's no reason not to put business logic in persistent
objects, as the persistent objects are not polluted by persistence-mechanism
specific code. Entity beans have lumbered us with some baggage in this area.

With JDBC, separation via a DAO does make more sense, as otherwise the JDBC
code can pollute the object model. However in the case of the PetClinic I
seem to recall there being a high level of duplication between DAO and
business objects. In this case, simple subclassing to handle the persistence
details in the subclasses probably makes more sense.

Regards,
Rod