About MVC

Motivation

Many web frameworks, regardless if MVC or component based ones, try to automate too much and share this "we want to solve anything generically" philosophy. That's fine but it comes with a price: Complex configuration models, complex runtime bindings and evaluations (e.g. expression languages), complex HTTP parameters to object mappings and vv, trying to merge the web designer's world with the developers world etc. The symptoms are well known to web developers: Hard to test, runtime errors instead of compile time ones, bad scalability due to more CPU and resource usage and too many multi-threading assumptions (e.g. synchronized code).

What does VrameWork MVC do?

Based on those experiences we needed something simpler, more scalable, easier to learn and adopt to the concrete project needs.
The MVC basis is really simple:

• An Action processes a request, calls any business logic and creates a model.
• This model is passed on to a View. All the action handling and rendering is pluggable but the default implementation uses simple conventions to map URLs to actions and views automatically.
  Sample: The Url http://localhost:8080/MVC-Sample/crm/CustomerList is mapped to the action ...crm.CustomerListAction and the view ...crm/CustomerList.html
• Views are created as pure HTML pages with simple tags, such as a PagedList tag which renders a collection into a page-able HTML table.
  <!--| mvc@PagedList:Customer customer: model, pageSize=8, listId=customers |-->
  
• HTML views/pages are translated to Java classes and compiled. There are neither expression language nor other runtime/reflection based evaluations of code. This makes it a) much faster and b) much easier to understand, maintain and debug.
  Sample: If your view visualizes a Customer object, you might print the customer's name in your page like this:
  <input name="customerName" value="|@((Customer))model.getName()@|" type="text"/>
  where |@((Customer))model.getName()@| is an inline code tag.
  
• MVC provides compile time tags to fully leverage the strong compile time typing of Java. This is a fundamental difference from typical tag-approaches and the reason why MVC can do without an expression language or reflection based code evaluations: Tags which are evaluated at runtime have no other chance than parsing and evaluating Strings. If these Strings contain code, the tags need an expression language or reflection to execute it. In other words: Runtime tags "mimic" Java code in a String which is interpreted at run time. Strange concept.
  It's important to understand the compile time tag concept correctly: Compile time tags do not restrict the flexibility of runtime interactions in any way. It's just compiled code which can do "anything" at runtime.
  And since compile time tags are directly generated and compiled into the view renderers, they are explicit, easy to understand and debug.
• VrameWork MVC also supports a conversation state (which is a sub state of the session) in order to enable users to work with several browser windows and all the pages still find their right state.
• VrameWork MVC pages can optionally be based on templates for easier and more maintainable pages.
  To base a page on a template, just add a <!--% Template:Template.html %--> tag to your page.
  Then, to replace one of the template's placeholder by parts of your page, do this:
  

  <!--% ReplaceBegin:MainContents %-->
    Your HTML goes here...
  <!--% ReplaceEnd:MainContents %-->

• VrameWork MVC provides a small, simple and practical JavaScript file for common tasks like managing lookup windows- or overlays, disabling buttons and links or displaying animated gifs.
• VrameWork MVC pages are small (a few KBs, they do not transfer any ViewState) and save download bandwith and time. Graphical enhancements are done through CSS and therefore cached by the browser.
• The server side state is small, MVC doesn't force you to use megabytes of session or conversation storage.

For more details please see the JavaDoc and the MVC sample application.

Note on web Frameworks

There are many web frameworks out there. They can be devided into

• Request-Response based ones, mainly MVC ones, like Spring MVC, Microsoft MVC, Struts, Stripes and others.
• Component based ones like JSF, ASP.NET
• Rich internet applications, e.g. Ajax based ones

A note up-front: There is no "good" or "bad" category, it's about the most suitable one. We are covering this topic from an easy to learn and scalable architecture perspective. We have seen many projects, either as software architects or as performance engineers, which work perfectly well for 500 concurrent users but break down (and must break down) when there are thousands.
There has been as strong trend towards components based frameworks in the last years because they promise to bring a familiar programming model (event based) to web applications. It's allegedly easier to have a "Page" object which reacts to "onLoad" or "onButtonClicked" events than to deal with HTTP requests. This trend seems to change again: Microsoft is pushing its MVC framework and in the Java space, many projects chose MVC frameworks. Why?

• Component based web frameworks try to bridge the gap between the request-response and the object/event based paradigm. To do so they introduce a lot of "magic" under the hood.
• This "magic" includes complex mapping mechanisms between HTTP parameters and object attributes and events. It makes it harder to understand, maintain and debug those frameworks. Complex mappings make the processing of a "page" slower because much of it has to be done at runtime, e.g. through reflection to translate HTTP parameters to object properties.
• The state of the components (e.g. the "active" status, colors and other UI chararcteristics etc.) has to be kept somewhere. Either on the server (by keeping an object for each component) or by constantly transferring the state between the server and the client. (Again, Ajax is a somewhat different story). JSF and ASP.NET use concepts like the "view state". While this concept can help to ease the programming, it can also slow down or explode the resources if not used wisely.
• This state management needs more CPU cycles for processing a request, many more long living objects on the server and/or a higher bandwith consumed by each request. (Long living objects are not good for the GC...)
• In addition, those framworks impose complex page rendering life cycles which again costs a lot of CPU power and create a lot of short living objects which have to be cleaned up by the GC constantly.
• Component based frameworks tend to be harder to test because you need to set up an almost fully running component environment to get a valid state for testing. MVC frameworks are usually easier to test. For example, simple unit tests might call the "action" methods of the controller.

Philosophical Debate

There is an ongoing philosophical or even religious debate whether a "good" MVC needs a configurable/de-coupled configuration of action- and page flow, e.g. like Struts has it. In our experience, most web applications serve a concrete purpose and it's quite firm that an "OK button click" will trigger a certain functionality or open a certain page. So in many cases, a de-coupled XML-based action configuration just causes additional effort to create it and even more, to maintain it. It's also an excellent source of runtime errors because it adds an additional complexity you need to handle.
In case of "really" dynamic and configurable flows, the typical XML-based action configurations are not enough. One would choose workflow or orchestration engines in such cases.