Alternatives to MVC for Web Applications

There are already many variations of MVC, Symfony itself, CakePHP, CodeIgniter say they use MVC, but it is not the pure standard, they say this does not scare the community with the thousands of layers they have.

There are several layers that assist the three main layers, such as a service layer between the controller and the model, the object transfer layer known as the DTO, repository, between the bank and the model, and so on. >

Choosing a framework to develop an application is the primary decision a developer can make. For it will lock the system to the model adopted for the rest of life, or be re-encoded.

I recommend you read on the blog of PHP creator, Rasmus Lerdorf, at criticizes what it does on the fashion of frameworks . He criticizes the creation of so many layers, which would be possible in an organized way and with much more performance.

Below are other layers that you can study if you are interested.

Service

The service layer is between the controller and the models. In this layer will be the entire business rule of an action, regardless of a user interface. By using a service layer you can isolate your business rules that involve more than manipulation of data. Leaving the controller to handle the processing the views require.

The main advantage would be the ability to rewrite your entire user interaction layer, or even create multiple, without having to worry about business rules.

A good example is the possibility of creating a web application and a mobile application communicating directly with the service layer, where each layer would have views and controllers.

If you used pure MVC, a lot of code would have to be rewritten in the controllers, since the rules imposed by the View on the controller may require different treatments or even return.

DTO

DTO is a standard that actually helps you standardize the communication data between layers, allowing in many cases the use of dependency injection.

Using DTO is a great way to program APIs or deal with webservices.

Repository

In the original MVC concept, the model is responsible for the entire business information usage rule of the system, so all manipulation and communication with the database are mixed in there. The repository layer appeared to separate the communication from the manipulation, leaving more readable and organized all the code of the model, besides allowing much reutilization of code.

MVP

In short, it's a direct model between a View and Presenter layer. Think of an application where the view makes Javascript requests, and Javascript itself fulfills the entire business rule. It is a model that has been growing a lot due to the scalability that it allows.

See the comparison of Frameworks in this template ,

Learn the difference between MVC and MVP .

-

Although the above mentioned layers appear to be only patterns, they are actually layers, even in the frameworks we use. An example is Doctrine that has the repository layer and Symfony create its model layers where all code makes use of the repository layer to communicate with the database.

It's worth studying a little about each one to see how layers are separated.

Some other suggestions Hexagonal Architecture that I do not have much knowledge to talk about.

MVC as a pattern?

In fact I classify MVC more as a layering than a purely stated pattern.

The MVC came to distribute the responsibility between the layers of the project.

It is very easy to add business rule in the middle of your VIEW layer, as this reduces cohesion and creates a high coupling of your classes. When we have the separate design in layers we can have better use of code, greater cohesion, less coupling and so on.

An MVC based framework is good because it makes it easy to use. A developer will know that you just need to move to a certain place to create an entry in the system and then create a place to receive and process the request.

What to use then?

There are several patterns that can be used to make your framework really usable. I could cite some as:

• Front Controller
• Intercepting Filter
• View Helper
• Dispatcher to View
• Service to Worker

Note that these standards can be used in an MVC project. The correct would be to understand how these patterns work, even if you are a developer of another language, and apply to your project.

Conclusion

MVC is a standard that works well, helps keep code healthy and practical.

Of course, even with the best framework in the world in the hands of a poor developer will not do anything.

What matters is to create a framework that is well done and can help in any way possible.

Good Caleb,   MVC is a great choice of pattern for a web application, although it was created for desktop applications, it is a perfect choice for the web because it separates the various layers / technology from a web application, M -> ORM / SQL, V -> HTML / CSS / JS, C - > C # / PHP, etc ...

MVC also offers the classic separation in three layers, data, logic, presentation.

What I like the most is the principle that it offers and that I try to use in all my projects, MVC or not, DRY (Do not Repeat Yourself).

There are already some derivations of the MVC, such as HMVC, MVVM, MVP, etc ... in which each one adapts well to the problem to solve.

I particularly like to use HMVC because it is the separate MVC in several modules / triads, and I'm even doing an HMVC framework :) "(crazy, no!?)", which by the way is super flexible and fast :)

link

PS: Attention is just my preference.

HMVC allows for example to have a MVC triad to handle various layout blocks, such as the header and footer, in the views or controller of the application, I can simply call the layout / header controller and then in the end 'layout / footer', without ever needing to dirty the called controller, who says layout, says other things.

This is an HMVC diagram, although in my framework you can also call an MVC triad from a view, as if it were a template:

andsomevideosexplainingHMVCusingCodeIgniter link