Doing MVC or not doing it?_问答_开发者_运维开发者技术经验分享

I'm new to MVC structure and feel it's harder to get things done because it's a new way of doing things. Are there anybody who开发者_JS百科 has experience of MVC vs. pages way of doing things. Is the MVC way of doing it the holy graal now or is there still value doing ordinary object-oriented development (or even procedural pages webdev)? Is MVC a fad?

A brief list of pros and cons for MVC

Pros

Testablily
Separation of Concerns - Promotes decoupling between major components
Helps you focus on one task/area at a time
Natural fit for Web and desktop interactions
Fits well with other design patterns, Single Responsibility Principle etc.

Cons

Can require more code and effort
Can reduce clarity for simple pages (in these cases try to continue using simple pages)
Will take more learning

MVC is much more than a fad. It is a very pragmatic way of separating multiple concerns of a web application into manageable and reusable sections. Granted it does take some getting used to at first, but with some conscious effort at breaking your application up the MVC-style can be very rewarding. Often solutions are more succinct as they only need to concentrate on a single operation or task.

It is not a new idea either. It has been around in one form or another since 1979 (@Sarfraz Ahmed's link) and has been used in various web and desktop platforms.

If you are finding yourself having trouble using an MVC-style implementation then try to break it down into the individual parts or actions that are being used, and their corresponding area, model view or controller. As you probably expected, this will come easier over time.

Good luck

To MVC or not is mostly up to the needs of your project. Sometimes I have simple stuff that doesn't need the Model, but can still benefit from a controller/view arrangement. In those cases I might go with a micro-framework ( for PHP that would be limonade ) or even less. Still the majority of my web projects are MVC applications.

I started making websites around 1996-1997, everything was kind of new and there was no sense to what might be a good or bad idea in the long run. Around 2005 when I left the military and got back into web development it wasn't that enjoyable to fight through rat's nest of organically designed code. So When I was introduced to Ruby on Rails and the concept of MVC, I instantly recognized for myself that this was a game changer.

As MVC is increasingly adopted in more and more web projects, its paving the way for the next generations of developer's lives to be a little easier and more productive by providing common ground across companies and projects. Yes MVC is a little tough to swallow when going from the upfront simplicity of cooperative script to page projects but anything worth doing isn't going to be that easy right?

With all that said, if you get a good grounding in MVC in one language, it can provide a mental common ground for you to learn other languages. As for how long MVC will last as a dominant framework design pattern, the software industry is like a desert, everyday things change and great ideas become eclipsed by better ones (XHR for websockets, embedded objects for native audio/video tags) but I think whatever finally dethrones MVC will be somewhat similar because it doesn't really matter how great an idea is if only a very small portion of people understand it.

If we speak about ASP.NET MVC, the framework page itself has a discussion on this point:

The ASP.NET MVC framework offers the following advantages:

It makes it easier to manage complexity by dividing an application into the model, the view, and the controller.
It does not use view state or server-based forms. This makes the MVC framework ideal for developers who want full control over the behavior of an application.
It uses a Front Controller pattern that processes Web application requests through a single controller. This enables you to design an application that supports a rich routing infrastructure. For more information, see Front Controller on the MSDN Web site.
It provides better support for test-driven development (TDD).
It works well for Web applications that are supported by large teams of developers and Web designers who need a high degree of control over the application behavior.

The Web Forms-based framework offers the following advantages:

It supports an event model that preserves state over HTTP, which benefits line-of-business Web application development. The Web Forms-based application provides dozens of events that are supported in hundreds of server controls.
It uses a Page Controller pattern that adds functionality to individual pages. For more information, see Page Controller on the MSDN Web site.
It uses view state or server-based forms, which can make managing state information easier.
It works well for small teams of Web developers and designers who want to take advantage of the large number of components available for rapid application development.
In general, it is less complex for application development, because the components (the Page class, controls, and so on) are tightly integrated and usually require less code than the MVC model.

I think this exhaustive list provides answers to all your questions about MVC.

Since you have not mentioned language and if you mean mvc in php then this is also a great resource for those new to mvc:

http://phpro.org/tutorials/Model-View-Controller-MVC.html

This is from a ASP.NET WinForms -> ASP.NET MVC perspective, however, ASP.NET MVC was the first time I heard of the MVC pattern (noob programmer) and I think if I discovered MVC in another language before ASP.NET MVC, I would've left ASP.NET/C# and went to that framework.

Learning and using MVC has made me a better programmer. I've always felt ASP.NET placed a transparent barrier between myself and the code (HTML or C#).

I've always wanted to break through that barrier, and MVC gives me complete control of everything in my app while emphasizing separation of concerns (something that makes coding infinitely more fun and less of a headache).

For me, MVC was the right choice.

The big advantage of MVC (in general) is that you are far less likely to create monolithic applications. You have a single request-act-response pathway, vs. something like ASP.NET webforms or JSF (although JSF is not as bad as webforms). It's very easy for a small site in webforms to become a big unmanageable tangled mess in webforms, then you have to start whipping out the custom controls and your team is lost. If you understand how the web work, MVC is easy ... although it is then in your hands to manage state.

After struggling with MVC for some time, I have to said that I now much prefer MVP (Model-view-presenter) architecture. Separation of concerns, decoupling and asynchronization are much easier to achieve with MVP than MVC, IMHO, because each MVC implementation doesn't split the concepts the same way, each controller doesn't handle the same things.