After some (bad) experiences, I am quite sceptical about MVC
frameworks. The hall of fame has accepted a few names: Struts, Play, Wicket... And then ?
Each period has its champion. Struts, as one of the elders, had a long period. So many developers had to use it. But what about software maintenance and evolutions ? Software dependencies between the model, the view and the controller can make moves very challenging. Struts 1 upgrade to version 2 ? What about moving to another technology ?
Quite a nightmare, it is sometimes easier to rewrite completely
the application. In my point of view, long term solutions rely directly on the
Java platform. The classic Servlet
/ JSP tandem
is not an MVC implementation but is plain and simple and evolutions are
easy. I understand JSF
enthusiasts. The solution is modern and interesting on a productivity
point of view. I have a personal problem with JSF (and others
share my opinion) : JSF and JSP are bad companions. What a shame for
While the RESTful architectural style is trendy, the idea of
and JSPs is interesting (part
of Jersey). Hope it will be part of the core specification someday.
Edit(2014-08-21) : the JAX-RS / MVC integration was part of the
JSR 339 initial request but was dismissed in the final specification.
A recent message on the
specification list let me have some hope...
Obviously, classes are structural elements. According to this same book, packaging is the act of grouping classes.
Something is bothering me about packaging. All programs I have been working on, and all courses I have been following, share a single vision of the way these groups should be considered.
In this single vision, classes are grouped on structural criteria. In a same package, we will find objects assuming a single role: DAOs with DAOs, entities with entities, controllers with controllers. To be honest, this helps designing interesting class diagrams. This has a real interest for building effective heritage hierarchies.
But in my point of view, we let apart behavioral criteria. One DAO object usually interacts only with a single entity class and a few services. This means, if we design sequence, activity or state diagrams, the involved objects will belong to different packages. This would be very helpful to help software maintenance: in a single set we have all the relevant elements.
Here is a summary:
Usually, package elements grouping is based on classes roles to help software design
Package elements grouping should also be based on classes interactions to help software maintenance
If we would like to design really modular applications, I think we should consider these two axes while packaging. On a pure design point of view, a class should belong to two packages : one structural (1) and one behavioral (2). This could be possible because one class usually has interactions with a few classes.
In Java, one solution to help set up this second kind of packages could be annotations. But the problem would be in class loading. This wouldn't be a real problem if we all time use to write APIs.
A pragmatic solution would be to change the packaging in the development process. Once the software has been designed building interesting heritage hierarchies based on roles, packaging should be modified to follow classes interactions in order to help software maintenance.