Framework Consequences

In my blog about dual persistence strategies, someone had commented:

Doesn't this result in tight coupling of view and model? What if we wanted to replace hibernate by iBatis, for example?

In my experience, this mindset of defensive programming only hurts projects as you spend more time developing ways to cleanly abstract models/services than simplifying the core competancies of the task at hand.

In the blog on dual persistence strategies, I mentioned using JSP tag libraries to support the view. I'm not going to slide around this one, it does couple the view and model-- producing a model 1 architecture. Yes, it would be difficult to suddenly switch to iBatis for persistence, but maybe I'm a unique case, but I've never changed persistence frameworks within an application. In using JSP tag libraries, the view becomes dependent on the persistence API you've chosen, which is fine to me. The view is the most volitile part of a web application and would probably be changed before the persistence framework is ever changed.

What if you didn't go with a model 1 architecture and opted to directly call Hibernate within model 2 'Actions'? Well, in a model 2 architecture, the controller Actions still support the view and act as an adaptor to your testable business model. Since the Actions support the view and are at whim for modification to support view functionality, the same consequences apply as model 1. If you now want to support sorting the data set in some view, you are going to have to add that functionality within the controller Action, if not the view. The same arguments apply here as above with model 1.

But I really haven't touched on my first remark on defensive programming. Lets provide two solutions to supporting the view with a persistence framework:

1. You've chosen Hibernate and use its API directly to pull the exact data you need in less than five lines of code within your Action.


2. You've chosen Hibernate, but want to accomodate a change to iBatis later. You create a generic persistence facade and create a Hibernate implementation of that model. To implement an Action requirement, you must modify the generic persistence model, and then implement it within your Hibernate implementation.

Now, everyone has their own opinion, but I would prefer to opt for the first choice. Instead of basically writing and maintaining a generic facade for your persistence framework, just make those calls directly. If some issue comes up where you do need to switch to direct JDBC or iBatis, just refactor that code. If you had written and properly maintained the generic goals of your persistence facade, you would still spend the same amount of time developing the new implementation as refactoring existing code. On top of that, it might be likely that your peristence facade was steered by the original implementation, and the new implementation would require additional changes to the persistence facade.

When would I choose a generic persistence facade? For non-view operations that I want to test within a main method, or if I was producing an application with specific requirements to accomodate multiple persistence solutions.