• Steep learning curve : With Spring, MVC controller support has a plethora of
options. As a result, developers need to know about plenty of interfaces and
abstract classes to make the appropriate design decisions.
• Hard to maintain : Now the application has one page controller per use case. In a
large application, this would lead to a huge set of controller classes, making it diffi-
cult to manage and maintain.
eInsure had a product workbench that was used by business analysts and product
designers to devise and roll out insurance products. Put simply, an insurance product
defines a set of rules used to underwrite a specific class of policies. One of the customers
who used eInsure wanted an offline version of the product workbench module. This
application would be installed on the laptops used by the business analysts. This would
enable them to work out the details of the product even when offline and synchronize
with the main database later, before finally releasing the rulesets.
There were two choices for this offline application. One was Java Swing-based desk-
top software, and the other was the same eInsure application running on an embedded
web server with a synchronization facility. Our customer preferred the first solution.
Since eInsure was being refactored to use Spring Framework, our initial take was that
most of the codebase (except the presentation tier view components) would be reusable.
The eInsure team was delighted about having moved to Spring because this Swing appli-
cation would run easily out of the container.
But soon our high hopes turned to despair when we found that even the page con-
trollers could not be reused. The reason for this was that the presentation tier code was
tightly coupled to the HTTP protocol and the servlet API. The page controllers imple-
mented the Controller interface and in the process heavily used HttpServletRequest and
HttpServletResponse objects. These objects were used to extract the data from form sub-
mission. The result was a set of page controllers that could not be reused outside a web
application. The development team was left with no choice but to build the application
from scratch, resulting in an unnecessary expenditure of effort.