RE: [Springframework-developer] Petclinic updated

[<pr...@se...>]

Before I comment, thanks for all your work on the demo Ken.  I haven't been 
able to contribute to the project for a few months, and due to work/family 
commitments, I probably won't be able to start contributing again until 
September.  I simply mention this so you can evaluate my comments accordingly 
(I value action more than talk, and right now you're acting, I'm just 
talking :) ).


>>I have just commited my latest changes to Petclinic. They include 
>>the following changes:
>>- ClinicImpl, ClinicDAO, and ClinicJdbcDAO have been replaced 
>>by AbstractJdbcClinic, HsqlClinic, and MysqlClinic.

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

Sorry to question your design choice, and maybe I'm totally missing something, 
just curious on what advantage this change brings.

Trevor D. Cook