Mike has posted 1 posts at DZone. View Full User Profile

Thoughts on modified MVC for web application development

08.15.2011
| 1816 views |
  • submit to reddit
I have been doing Java EE development for a long time, almost as long as Java EE first started way back before it was branded as Java EE.  I have noticed a lot of trends in Java developers’ work and one trend I consider most disturbing is a tendency to continue to do things the way they have been done before without asking the question, why?  Nowhere is this more apparent than in the use of the highly popular modified MVC pattern for web application development.  Ever stop and ask yourself...
   
    Who thought this was a good idea and why am I still using this crappy pattern?
 
    MVC a crappy pattern?  What?  Heresy!  Let me give you my thoughts.

    Back in the beginning of Java EE, back before Struts, back before Spring, and back almost even before Tomcat (the first commercial release of our software was on a pre-1.0.0 beta version of Tomcat) I went looking for best practices for developing web based applications.  At the time, I read white papers about the modified MVC pattern and on the surface it sounded perfect; Requests come in to a “controller” which gathers and stores all of the required data then the “controller” passes the request onto a “view” which renders the display.  Nice and easy.

    So I started to implement this pattern for our software product and it became apparent very quickly the modified MVC pattern as described was failing miserably.  Why?  Well at that time the product I was working on was eCommerce software.  Customers would give us their product databases and we would create custom websites for them which served as their online store. We put their product data into our database and our database stayed the same, but the front end for each client was completely custom.  Keep in mind that nowadays everyone has an online store but back then this was the fledging beginnings of eCommerce.  We had a true graphics design team which worked exclusively on the front end and, as I mentioned before, each client’s online store was completely customized to their needs.  Now of course all the sites had the same basic parts – login, account management, product search, product category browsing, sale items, specials, up sells, etc. – but since each client had a custom built online store, we had no idea how many pages the site would be or what would be on each page.  For example, one client wanted nothing but a splash screen for their “home” page but another client wanted their homepage to be filled with as many clearance, sale, and specialty items which were in their database.  Looking at this problem from an MVC point of view, how is the “home controller” supposed to know what to load for each client? I suppose the "home controller" can get that info from the database, but is that a good idea?  Worse yet, how is the graphics design team to know the list of items on sale is magically stored using the “saleItemsList” key. And worse of all, how were we going to make “controllers” to handle page navigation requests when we had no idea what the navigation was going to be or what will be on the pages!

    Once I realized this modified MVC pattern was going to fail miserably, I stepped back and started thinking about the problem to see if I can come up with another solution.  The solution was quite obvious.  Every page of the website is divided into logical pieces.  One piece shows account summary information; Another piece may be static text; Another piece a list of shirts which are on clearance; Another piece a list of categories to drill down into your product catalog; Another piece site navigation, etc.  Now if you take this idea to the extreme you get the Portlet API, but keeping this grounded to the EE API, easily leads you to custom tag Libraries.
   
    There is no reason why each of these pieces could not be nicely encapsulated inside a custom tag.  Custom tags are “HTML”-ish so a graphic’s design team is comfortable working with them and the TLD descriptor (if you use <description>) describes the tags, and all of the tag’s attributes.  Even better, when the graphic’s design team wanted the list of sale items, they knew all they had to do was…
<abc:SaleItems var=”theListOfItems”>
…
</abc:SaleItems>

…and did not have to worry that one “controller” used the magic key “saleItems” to store the list but another “controller” used “salesList” as its magic key.  The custom tag describes what data is being retrieved and attributes can be added to customize the tag as needed.  Custom tags are grossly unused in my opinion.  I have interviewed developers who have 10+ years experiance who have never coded a custom tag.  I have even had developers on my team not believe me when I tell them they can create their own tags!

    This idea of breaking the software into a library of custom tags which are responsible for retrieving data proved to be much easier for development team to code and much easier for the graphics design team to create custom website.  It completely removed the need to go to a “controller” for navigation which enabled the graphics design team to (now pay attention because this is really quite remarkable) create hyperlinks and site navigation which went directly from one JSP page to another.  Yes!  Believe it or not it is possible to do navigation in a web application without first having to edit some configuration file to map a URL to a “controller”, then developing a new “controller”, then defining some universal key which specifies the view response, then mapping that universal key in some view technology configuration file, then mapping to another key is some page template configuration file which then finally specifies your JSP page. 

    This idea though does not fit nicely into the modified MVC pattern used for all web application development, and that is a problem.  However, somehow we have been sold on the idea of a "controller" retrieving everything needed to display on the page (which makes changing the page hard) and storing that data using magic keys, which aren't documented anywhere except in code, and relying on everyone to just somehow know every key which exists and holds data.  We go great lengths to separate DAO's and services into single pieces of responsibility so it is easy to reuse the code (need product data, look at the ProductDAO, duh!) so why do we not do the same thing on the web tier?  Why do we continue to dump data into a key-value black hole with no really good way of determining what's in there?

   It is sad we are in this blind mentality to follow the modified MVC pattern.  At every job I have I try to explain to my colleagues there is another way, but mostly I get stunned silence because they are so brainwashed on this pattern they cannot imagine another way of doing things.  We, as Java Developers, are in a field where it is our job to develop innovative solutions to problems and doing more of the same is not innovative.

    Now, does this mean modified MVC is all bad?  No of course not.  But just like XML, Struts, Spring, AOP, Web Services, Dependency Injection, and whatever-other-technology-was-suppose-to-save-the-world, modified MVC is one of many tools which we should be knowledgeable of and use according.  Like every other technology or pattern, if you force it to be used everywhere, you will end up using it in many cases where it not needed or worse not appropriate.

 

0
Published at DZone with permission of its author, Mike Dzone.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Sivaprasadreddy... replied on Wed, 2011/08/17 - 12:36am

Hi,

I am glad to see atleast someone is looking at correcting the core problems of java web development instead of running after JVM dynamic languages like Grails, Scala, JRuby etc etc.

Thanks,

Siva

 

Manjuka Soysa replied on Tue, 2011/08/23 - 5:32am

MVC is obsolete in modern AJAX-based 'one-page' web applications. I think SSJS (Server-Side-JavaScript) frameworks will become more popular in the future - one language on the browser, application server and possibly even the database.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.