Reasons not to use MVC architecture for web applic

问题:

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?

回答1:

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.

回答2:

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.

回答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.

回答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.

回答5:

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.

回答6:

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.

回答7:

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).

回答8:

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.

回答9:

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.

回答10:

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.

回答11:

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.

回答12:

You can refer to following

http://blogs.msdn.com/b/webtopics/archive/2009/09/01/asp-net-mvc-what-is-it-and-should-i-use-it.aspx

and http://msdn.microsoft.com/en-us/magazine/dd942833.aspx#id0080017 refer "Undisputable Facts".