Re: [Springframework-developer] Petclinic updated

[Ken K. <kk...@kk...>]

Trevor,

I'm really glad you asked :-) .

Really, I do appreciate your questioning this design decision and truly 
welcome more criticism. It helps me learn.

I first got the suggestion from Juergen:

<Juergen>
Regarding the implementation: I've noticed that the Clinic interface duplicates ClinicDAO's methods to a large extent, and that ClinicImpl adds cross-referencing and caching to the entities (data access aspects). This isn't really proper separation between data access code and business logic, but of course the borders are often somewhat blurring. In our case, it's probably more appropriate to merge the two, i.e. offer just a Clinic interface, with the common logic in an AbstractClinic base class, and a ClinicJdbcImpl default implementation.
 
IMO, the app simply isn't complex enough for separated business and data access layers. The more important thing is clear separation between the business and the web layer: Those two should never be merged, not even in very simple apps.
</Juergen>

These comments really hit home because I was already not liking the smell of that duplication in the Clinic and ClinicDAO interfaces, but I really didn't understand at the time why this should be so.

When Rod seconded this opinion, I agreed to go ahead and do it, although I was still a bit unsure about it.

While doing the refactoring, It finally dawned on me as to why this approach makes sense for this app. The situation really became clear to me while I was writing the new TestCase for Owner (+1 for XP).

The application is all about database access and there is very little business logic in the application outside of that. What few business rules there are have been implemented by the Validators and the Owner class.

Therefore, this change doesn't really exclude other options as you can just provide other classes that implement the Clinic interface, i.e. XmlClinic, EJBClinic, MockClinic or whatever. Since AbstractJdbcClinic doesn't really implement any business logic besides persistence, there is no need to derive from it except for Jdbc purposes. The reason why I didn't implement an AbstractClinic class as Juergen had suggested was simply because I couldn't find anything for it to do.

I think the advantage that this change brings is that is simpler and clearer and as such suits the tutorial purpose just a little bit better. There actually is no clear and strong advantage to either implementation choice for this situation, IMO.

Regards,
Ken


pr...@se... wrote:

>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
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Parasoft
>Error proof Web apps, automate testing & more.
>Download & eval WebKing and get a free book.
>www.parasoft.com/bulletproofapps1
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>