Hi MVC fans,
 
First, let me quote Martin:
 
<quote>
Hiring people that already knows Struts or Expresso is very desirable? may
be true, if you accept that frameworks are difficult toys with expensive
training behind, all your arguments make sense in this case. But what if a
framework is very easy to adopt??? The Servlet spec is a framework in
itself, so IMHO, a productivity oriented framework should be a very thin
layer over the spec features, so that any one that knows how to program Java
& Servlets, would be able to work with a given framework in very short time,
then I would not care if I hire a programmer with Struts, IBM
ServletManager, WebMacro, Oracle JDeveloper or Expresso experience!!!
</quote>
 
Now let me quote a recent TheServerSide.com post of mine:
 
<quote>
Clean MVC is indeed a no-brainer for many types of applications. I have introduced an extremely simple approach to my team: Basically custom controller servlets that do all the processing and view JSPs that render the results. Instead of custom controller servlets, you can also use JSPs that just contain Java code and redirect at the end (JSPs with automatic recompilation may be easier to handle for HTML developers). This approach has been sufficient for more than two years, numerous web applications, and numerous Java web developers and HTML designers. 

Conceptionally, these custom controller servlets are similar to Struts actions and can do everything those can do: populate one or more plain beans used for forms or parameters, perform validation, process data, generate results or errors and put them into request or session scope, redirect to an appropriate view. They can be mapped to action URLs via standard servlet mappings. Init parameters like view URLs can be handled via Servlet init parameters, global ones with ServletContext init parameters. This is easy to understand, extremely flexible, does not need many lines of code, and works nicely without MVC framework restrictions and without overhead. 

The only "libraries" necessary for writing controllers are something like the Jakarta Commons BeanUtils class for populating beans from request parameters, and a simple ActionServlet base class to ease controller implementation. 

View JSPs can be written nicely with JSTL (JSP Standard Tag Library) and its EL (Expression Language). But even without any tag library at all, view JSPs and not hard to write and maintain if you can live with some simple JSP expressions and scriptlets (even by HTML developers, in my experience). Forms contain the mapped action URLs as targets and can be filled with current values from one or more appropriate beans in request or session scope. 

Note that I do see fields of application for MVC frameworks like Struts or WebWork, especially for large applications and large development teams. But for many types of web applications, I don't really see a need for more than some simple custom guidelines for MVC design, accompanied by a few helper classes and a good tag library like JSTL. 
</quote>
 
IMHO such an extremely simple framework does not need a lot of training: It's kind of obvious how things work for someone that understands the basic MVC pattern. Debugging and testing? The "framework" is only a few lines of code, no real sources for bugs here. Note that this approach has worked nicely for numerous developers in my team, as stated above. Reinventing the wheel? No, just applying KISS and sticking to it: A very thin layer over the Servlet spec.
 
The Servlet spec 2.3 (assuming a compliant container) provides so many goodies - use them. Utilize lifecycle listeners and filters. For applications that are simple enough, use container authentication, web.xml init parameters, ServletContext logging. Use more sophisticated solutions like custom authentication, custom config files, logging toolkits only if you need to. And use JSTL and its EL for bean property lookup, error message lookup, loops, conditions, i18n, number formatting, etc if you don't like Java in your JSPs.
 
For the layers beneath the view layer, J2EE compliant web containers (like Resin 2, JRun 4, or Tomcat 4 + Tyrex) provide JNDI DataSources, JTA transactions, etc. IMHO an MVC solution does not need to address these issues at all (but both Struts and Expresso do, in their own way) - I prefer sticking to the respective standard mechanisms. If it makes sense for my application, I want to be able to choose an O/R toolkit (like OJB or Castor) - I'm not a fan of integrated toolkits like Expresso's DBObjects.
 
BTW, "thousands of people contributing" to Struts and/or Expresso... Well, let's keep it realistic: I suppose there are just a few people contributing significant amounts of code, and a few more contributing valuable bug reports and enhancement requests. The rest is simply trying to understand and use the framework. With thousands of real contributors, the codebase would be a mess...
 
If I want to have a higher level of GUI abstraction to avoid confronting HTML designers with Java technologies at all, I'd probably choose Tapestry or something similar (although I'm not too familiar with those). But I don't consider that very important in a developer-centric company with HTML designers that know basic Java or, preferably nowadays, JSTL. JSP views that pull data from the model and directly address controller servlets is less bloated and more flexible, and not too hard to maintain.
 
Simply put: Why use a certain framework if you don't really need that type of framework because standard mechanisms and a few simple patterns achieve the needs of your application? Options that you don't need and complexity that you don't take advantage of will just confuse you (and especially newbies, for that matter).
 
Regards,
Juergen