Should new web applications follow the MVC or MVP pattern? [closed]

Question

Note that I am not asking which to choose (MVC or MVP), but rather if one of the two should be used for a web application.

I realize that it might be too much work to convert an older application from its current design to a MVC or MVP pattern. However, what about for a new app? It appears these are the most popular architecture patterns, so should one of these be chosen? If not, what other patterns are there?

If you are not familiar with MVC and/or MVP, a good question to check out is "What are MVP and MVC and what is the difference?". It has many good answers, including links to various websites that break down each one.

Answer 1

MVP / MVC works well in web applications because the HTTP verb + URL combination is a very good way to determine which action to take. There are reasons not to use it, such as if your team has a lot of experience with another framework, but I would generally recommend an MVP / MVC framework. Your application will be finished quicker with higher quality.

Answer 2

Both are great options.

I'd go for MVC as it has a wider adoptions and its easier to understand and use to frontend (HTML / CSS) developers.

Also, given the number of frameworks adopting the MVC pattern, chanches are talking with your coworkers in MVC you will talk a well knew language.

Answer 3

I have posted the following answer for another question, though it may be more appropriate here.

MVC is good for plain server side scripting. In MVC developers always try to keep the controller very lean. Mainly controller is for just selecting the appropriate model and reflect on the view. But in today's web applications the View part has radically changed and became complex enough to produce a big, fat and messy controller. So now we need a new place to put the user interface's complex control logic. Here the P of MVP comes in that is the presenter. So presenters are responsible for controlling the logic for a particular user interface component. Don't worry the controller is still here, named as Application Controller. Which ultimately responsible for switching between comparatively larger application components. So MVP can also be said MVPC(!!). BTW this was my way of understanding MVP and obviously not any ground rule.

So I am already tend to MVP for complex web apps.

Answer 4

Your question was "should I use one of these design patterns".

I'd have to say that that really depends on the scope of your project. On a very large project that has interdependencies with other systems in a large organization with a large budget, I'd say they are definitely worth considering.

I think these patterns are often over-used on smaller projects where they may add unneeded complexity and cost.

The main point of loose-coupling, is so that you can change your DB or UI at a later time, or re-use business logic. Often times, this never happens. You have to realize that either of these patterns will take longer to implement and complicate the code quite a bit. So, I strongly suggest really thinking this over and weighing your options. You can often deliver a better solution faster by using a very simple architecture that gets the job done and reduces complexity!