Drawbacks of using MVC

[Syed Hussain]

We only hear what the benefits of the the MVC pattern are e.g. seperation of roles etc. but is there a drawback of using MVC pattern?
I dont know if I am correct, but one drawback that comes to my mind is that number of objects working concurrently increase. Hence an application will use more memory compared to other applications. Is this a valid issue during application design (especially for constrained environments e.g. PDAs) ?

[Frank Carver]

This might be a problem, certainly one of the implicit drawbacks with many patterns is the increased complexity of the solution compared to a more naive approach.
I think you have to be sensible about this, though. Use of a pattern such as MVC can often also lead to better division of responsibilities between objects, which in turn means that the objects in the system can be much simpler and smaller. In any resource constrained system, refactoring to achieve "Once and Only Once", is vital, and a solution which has any duplication of code is probably not a good solution.

[prashant patel]

Only drawback of MVC is how you model your mvc with relation resource like mapping to url, redirection, are you hardcoding? where to redirect? if you go on and implement your own mvc then you need to take care of such thing but again you have struts which has a great framework for MVC. if you implement your own mvc then you tend to be getParameter() typish passing a lot of
parameter for the decision to be taken, hence a lot of javascript then it really becomes a mess. struts solves this. Again struts has a long compile deploy cycle especially deploy.
botton line - it all depends on how you achive mvc.

[Frank Carver]

I didn't think the original poster was particularly asking about MVC in web applications. MVC is a kind of "pattern", and as such is usable in a variety of situations and may be implemented in many different ways and different languages.
Sure, struts embodies a sort of MVC pattern for web application development, but so does WebMacro, for example. And many people have written traditional "desktop" applications using MVC.
May I ask for a bit more detail from the original poster about the type of application being considered ?

[Junilu Lacar]

Syed,
You might also want to read some of Allen Holub's criticisms of MVC in this article

[Frank Carver]

Interesting article.
I'm not sure I agree with his interpretation of what MVC is, though. In the article MVC is taken to imply "UI knows too much about the model", and yet his suggested alternative solution is equivalently "Model knows too much about the UI".
He tantalises us with mention of a "visual proxy pattern" to solve this, but at the same time puts his head in the sand and declares "I would argue that that there is only one "best" way to represent [the data] for a specific problem domain." I guess he's never worked on a a web UI which has to generate different HTML to support different browsers, or varying corporate look-and-feel, or even anything with user preferences such as a word processor.
I, too, dislike "Rapid Application Development" (RAD) software, but I can't help thinking that this ill-informed rant is not really the answer.

[Matthew X. Brown]

I think that many times the biggest knock(of MVC) is that the "view" layer is not truly separated from the other layers. In the J2EE Design Patterns Book by John Crupi and others, there is a point that they make about using a java helper class with the view-which is described in View Helper pattern. Basically, if you do have business logic in the view tier(which is quite common), you should put all of it in a jsp "helper" class or tag library, so that your jsp code doesn't contain "spagetti" code.

[Josh Rehman]

Layers give you the benefits of decoupling for the cost of increased complexity.
In other words, the drawback of MVC is added complexity. Note, however, that this complexity stays fairly stable while the system's overall complexity continues to increase. Therefore, MVC makes sense for more complex systems.

[David O'Meara]

It can also be a drawback when the views are cut into 'component parts' like menus, headers, footers etc and this concept gets taken too far.
It can happen that the views get some controller-type responsibility to define the next level, and that level might define sub-layers too. Turns into a type of MVCVCVC...
We had something like this once (in a web app) when the creative wanted us to retain the html extension. We had a JSP with a static include to the HTML source. This HTML could include JSPs too, but these JSPs included their code in a HTML file. We rather quickly ran into 6 or more levels of files to trace where the output came from
I've also seen serious MVC problems (again in web apps, I don't do Swing ) when the controller tries to maintain the view when the page includes frames.
Another source of error is the choice between individual and Global (or front) controllers. Poorly managed Global Controllers get heavy and ugly real quick. The most amusing ones are the ones that aren't built on a coherant framework and end up as a massive switch statement.
The other side is the individual Controller that doesn't do anything. Again you'd have to weigh the complexity overhead, but putting a controller in front of a bunch of essentially static pages may be undesirable.
I was in the middle of writing an article on the dark side of MVC, but I might not bother since most of it is contained here
Dave

[Pho Tek]

Hi,
Let me give my perspective - as I'm in the middle of a project that uses Struts.
Several issues to note:
1) Compound JSP versus many JSPs.
Manning's Bitter Java book explained the ugly side of Compound JSPs - i.e. JSPs which makes decision on what to display via taglibs (in conjunction with request params). In this case, the JSP is actually checking conditionals on what to display and I think that doesn't belong to the view tier.
The downside with creating individual JSPs for CRUD functionality is the proliferation of files.
We ended up with some compromises e.g. Edit and Add shares the same form by using Runtime expressions.
2) Templates, templates, templates.
A previous poster mentioned that getting carried away with separating the view into headers, footers etc.. I don't think this is evil in any way. This if the foundation for widely adopted Frameworks like Tiles & webmacro. An alternative would be to send the value objects for presentation as XML and employ XSLT to warp it according to a theme/skin.
3) The flow of the application.
This is probably the single most beneficial attribute of MVC - a centralized flow definition. The downside is when the struts-config.xml file becomes to complex to edit (e.g. 200+ action mappings) That's when some viewer tool like Camino helps. Camino product
That's my 0.02 cents worth on the topic.
Cheers,
Pho
[ September 17, 2002: Message edited by: Pho Tek ]
[ September 17, 2002: Message edited by: Pho Tek ]

[Syed Hussain]

Thanks for the interesting replies.
Frank, I agree that we must re-use as much code as possible but that does not mean that without MVC this is not possible to achieve. I believe that in Swing based applications it is vital to use MVC as it leads to better seperation of responsibilities. If anyone knows of any other pattern that is as effective as MVC please point it out.
This post was orignally not intended specifically for web applications, but the real "ugliness" of MVC pattern comes in web applications.
Here is the scenario, We are supposed to develop a web application. We orignally intended to use a framework for developing the application, but the problem is we have hardware limitations and cant afford a licensed application server.
Therefore, our team decided to make as less usage of memory as possible and at the same time make the application design as simple as possible.
The problem with Struts and other frameworks is that they use heavy usage of memory and slow the application down considerably as there is a lot of redirection and lot of resources are kept in memory e.g. the configuration file in case of Struts is kept in memory and it considerably large.
Hence we have decided against using any framework because of the fact that we wanted to keep the number of in-memory objects to a minumum. Is this a valid issue ?
If we make our own MVC implementation it wont be as flexible as Struts , problems like hardcoding urls will arise as pointed out by Prashant, and it can become very ugly when the number of pages increase as David pointed out.
So, I believe that the best solution is to use simple jsps for handling posts and using "View Helper" strategy.

[Syed Hussain]

Originally posted by Pho Tek:

The downside with creating individual JSPs for CRUD functionality is the proliferation of files.
We ended up with some compromises e.g. Edit and Add shares the same form by using Runtime expressions.

Pho, What is CRUD? can you elaborate this point. Cant seem to understand it.

[Frank Carver]

What is CRUD?
It stands for "Create, Retrieve, Update, Delete", and is shorthand for the four basic functions of any data storage application.

[Frank Carver]

If we make our own MVC implementation it wont be as flexible as Struts , problems like hardcoding urls will arise as pointed out by Prashant, and it can become very ugly when the number of pages increase as David pointed out.
So, I believe that the best solution is to use simple jsps for handling posts and using "View Helper" strategy.
Especially if you are resource constrained, I really don't think that using JSP is a solution you should jump for without a lot of thought. Just as J2EE does not mandate EJB, it doesn't mandate JSP, either.
I have found that a templating approach (Webmacro, Velocity, FreeMarker etc.) allows just as much flexibility in a simpler way. And you don't need to deploy the Java compiler on your server!

[Junilu Lacar]

Originally posted by Frank Carver:
In the article MVC is taken to imply "UI knows too much about the model", and yet his suggested alternative solution is equivalently "Model knows too much about the UI".
I, too, dislike "Rapid Application Development" (RAD) software, but I can't help thinking that this ill-informed rant is not really the answer.
This was written a while back and I've tried to work through all six parts but just haven't manage to yet . I did run the final application and it's kind of cool because the view changes on the fly when you resize the frame.
The article did make me wonder whether the objection to "Model knows too much about UI" is a just a sacred cow. I haven't tried implementing the visual-proxy pattern in my own work so I have no idea if it actually does live up to the author's claims.
As for "UI knows too much about the Model", if you look at Struts, I think this problem becomes evident. In pre-1.1 versions, ActionForms were very still coupled with the JSPs and the underlying "model" object. For example, if you were displaying an address and needed to add a field, say Country, you'd need to change the JSP, change the ActionForm, and change the Model. This is reason for the creation of DynaForms, to eliminate the need to manually create/maintain so many ActionForm classes.
In contrast, from what I understand in Holub's article, the only changes you'd need to make using the visual-proxy pattern would be to add the Country attribute to the Model and the Proxy, which are naturally tightly coupled. Somehow, the JSP (the view) wouldn't have to change (I suppose by using a custom tag or something to make the Proxy render the view). But like I said, I haven't really tried to implement this but I think it could be worth a look, even if only to prove to myself that it's not the answer. (That is when I find some time to do it )
Holub also mentions using the Customizer interface when creating views for JavaBeans instead of using getters/setters. Has anyone here done anywork with Customizer?

[Frank Carver]

All this highlights again (to me at least) that JSP and MVC don't really work very well together at all. Most of the objections to MVC that keep cropping up are actually problems in particular implementations (JSP in general, and Struts in particular).
To me, the point of MVC is to split responsibilities so that control flow is the sole responsibility of the controller, look and feel is the sole responsibility of the view(s), and business logic is the sole responsibility of the model(s). Anything which slops over those boundaries is getting further away from "pure" MVC.
I don't want to appear as if I'm "banging on" about this, but I would recommend anyone to take a look at some of the examples and documents at http://www.webmacro.org/ to see how a clean MVC approach can be applied to web applications.

[James Mead]

I agree with Frank - I think you should be careful to draw the distinction between the MVC pattern itself and implementations of that pattern e.g. in a web application.
I think there is little doubt that the MVC pattern itself is a very valid OO way of dividing responsibilities. There is also little doubt that Java web applications (and in fact web applications in general) struggle to implement the MVC pattern cleanly, even using frameworks like Struts.
I've worked on both windows applications and web applications and it's clear to me that the infrastructure for web application has to improve before it will be possible to have clean implementations of the MVC pattern.
I think the new JavaServer Faces may address many of these issues and make it easier to develop more elegant implementations of MVC in web applications.
Here's hoping, James.

[Syed Hussain]

Thanks for your recommendation.
I`m having a look at WebMacro since Frank has been banging on about it
Regarding Java Server Faces, what I know is Craig McClanahan is Spec Lead of both Struts and Java Server Faces. What effect will this bring to the Java Server Faces technology ?
Maybe Java Server Faces will eventually merge Struts into itself, which will be good for some and nigthmare for others

[Chris Mathews]

There is actually a news posting on the TheServerSide about Struts and JSF Integration. Check it out here:
Craig McClanahan Announces Struts and JSF Integration Position

[Ilja Preuss]

For an alternative to MVC see http://c2.com/cgi/wiki?ModelViewPresenter