Reasons not to use MVC architecture for web application

Question

In the past I have primarily built all my web applications using an N-tier architecture, implementing the BLL and DAL layers. Recently, I have started doing some RoR development

Answer 1

For certain pages, MVC can be a little overkill:

• splash pages
• landing pages
• marketing pages that are going to be thrown away after one use
• one-off's

It's easy to get wrapped up creating a beautiful MVC architecture, when a small page, concisely written, can be OK on these situations.

MVC may also be impractical if you're in time trouble, and you need something out REALLY fast. Like your marketing team is out at a conference, they're having trouble, and needs something to show in their booth this second before they lose their biggest customer.

Answer 2

The only drawback we've had is that MVC pushes you toward a html/javascript interface where rich internet applications become more difficult. For example if you want to present the user with a calendar control, you may need to roll your own since you can't drop one on from the toolbox. That said, MVC is great. When we really need RIA applications we use MVVM and Silverlight.

Answer 3

The simple answer is, no.

MVC is all around a better architecture than your old-school n-tier architecture, for many reasons. It's the standard approach in other UI models (e.g. Swing). The only reason it took so long to make it to web applications was because it took the software community, collectively, a little while to get used to the statelessness of the web and to be able to deal with the views and controllers in a way that made sense.

Answer 4

Life above the service tier suggests you should use the MVC pattern in a way that adheres to the SOFEA principles, and watch out for "Front controller" type frameworks disguising behind the MVC acronym. (or, you can still use them, but at least read the article, understand the differences and choose wisely).

Answer 5

One of the factors could be the statefulness of your web application. If it's a basic web application that gets everything from the server with a few JavaScript hooks such as client side validations, then the Rails type MVC is really great. I am not familiar with MVC on ASP.NET, but I've heard it's similar to that in Rails.

If the web application is really stateful, then a better approach would be to have a dual MVC layer - one on the client side, and the other for the server. The MVC on the server will mostly concern itself with authentication, authorization, churning out data in standard formats, etc. The client side MVC will concern itself with things such as DOM events, user actions, how they affect the application state, and how/when should data be requested/sent to the server.

MVC is just a way to organize code, just as BLL or DAL would do. MVC in Rails basically hides DAL altogether by using a set of conventions. Usually business logic resides in the models itself. However, if your application demands more complex BLL where object interactions can be intricate, then there's no reason why that BLL can't peacefully co-exist with the M in MVC.

Answer 6

I don't use MVC only on really tiny projects consisting of ~1-2 files and ~10-20 lines of code. And they will hardly evolve into something bigger.

But if they will, it will be time to rearchitect them into a MVC ones.