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 as well as looking into ASP.NET MVC.

I understand the differences between the different architectures(as referenced by some other SO posts), but I can't really think of any reasons why I wouldn't choose an MVC model going forward for a new project.

Is there any reasons/times in your experience when an MVC architecture would not be suitable, or any reasons why you would choose a BLL/DAL architecture instead?

Answer 1

I don't think your options are mutually exclusive. You could perfectly use MVC while using BLL/DAL for your model logic.

You can implement the M part of MVC as you prefer, there is no restriction about that. Using BLL and DAL would be a valid option.

Answer 2

The only reason i can think of right off is that ASP.NET MVC is not always available. I remember having to explicitly check that box in the Web Platform Installer.

Other than that, it's a matter of personal preference. If you're used to the traditional way, it may be easier to stick with that than to learn/use a whole other model. There's nothing inherently "wrong" with the old tried-and-true way, no matter what the architecture astronauts tell you.

Answer 3

For me? the only reason I'd not use MVC is because the application I'm working on was already started in web forms. I'm not a big proponent of scrap/rewrite, but anything new I do is in MVC.

Answer 4

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.

Answer 5

We have already use the MVC for the Windows application,Now we need to convert that thing in the Web application we don't have any problem in any thing. We are using the Web service and every Business Logic is in the Web service. So you can use the MVC in the web application. M-Model(Functions and Procedure which communicate with Business logic) V-View(Design) C-Controller(Form Logic) so that is no connection in the DAL,BLL and in MVC. you can define your Business logic and use in it any where in the MVC. That's my point of view MVC is very useful for Re-usability i prefer if your application is big then you must use MVC.

Answer 6

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 7

I wouldn't use MVC pattern only in the case when I have an existing desktop application built with MVP and I have to convert it to a web environment. That's because I already have written logic for presenter.
In any other case I would use MVC.

Answer 8

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 9

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 10

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 11

Personally, I would rate it based on the complexity of the target application. MVC (or more structured approaches in general) lend themselves very well to large scale applications where design consistency and segregation of code is a benefit outweighing the cost of supporting the design.

If its a small site, or very few pages/controls, I would avoid sticking to strict design patterns. But that is just my preference.

As one poster said, you also have to consider the state of any existing applications, and your development team skills / experience.