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:

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

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?

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.

 

 

 

Any questions? vramework@vramework.org