Just so that you don’t think that I’m the only software architect that believes that MVC is Dead — here are some other references for you:
[1] MVC is Dead, it’s time to MOVE on.
I’m certainly not the first person to notice this, but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don’t know where else to put it.
To fix this I’ve been using a new pattern: MOVE. Models, Operations, Views, and Events.
Well it’s hardly condemning MVC to the rubbish pile and really only creates an alternative way of laying out MVC type architectures, but it shows that even back in 2012 when this article was written, the writing was on the wall for MVC.
[2] Discussion thread for the previous article
“Everyone who has done MVC long enough… The controller should have and only have logic which absolutely cannot be moved to a service layer.”
Sorry, which letter in MVC is the “service layer”?
One of the reasons I don’t buy into MVC is that MVC doesn’t mean anything any more, and hasn’t ever since the web people got their hands on it. If you ask ten developers what MVC is and get 13 different answers (see half the sibling replies to this comment), well, that’s not itself a problem, but it does mean that running around telling people that they should or should not do “MVC” has been pointless for a long time.
Nobody seems to know what goes where in MVC anyway.
[3] MVC Is Dead, What Comes Next?
So far we have only touched the surface of functional reactive UI development, but by now it should be clear that this approach has some tremendous advantages. Future articles will go deeper into the technical details, but also show the disadvantages (or let’s call them “yet-to-solve-challenges”), and show an example how the lessons learned can be applied to JavaFX applications.
This article explores the separation of front end from back end, and discusses functional reactive programming, which is a great helper for front end development but not so necessary at the back end. Which all goes to show that completely different paradigms may be necessary for front end and back end. When you’re able to separate out the front end from the back end and do away with the MVC structure, you can apply the paradigms that best suit the problem that needs to be solved.
[4] Why I No Longer Use MVC Frameworks
The pattern behind every screen we use is MVC –Model-View-Controller. MVC was invented when there was no Web and software architectures were, at best, thick clients talking directly to a single database on primitive networks. And yet, decades later, MVC is still used, unabated …
We are trying to use an obsolete architecture to solve problems that no longer exist in the real world.
[5] MVC is Obsolete
So why am I telling you that MVC is obsolete?
Because in the past few years, most of us, backend web developers have lost our views.
If you don’t have a view and you’re just discussing separation of your data models from your business logic, why use MVC?
[6] Simplify Your Laravel Project With a Folder-By-Feature Structure
By default, Laravel stores files in a folder-by-type structure … This folder structure works ok for small projects, but as soon as you write more and more controllers, models, etc. it gets very hard to find the actual file you are looking for.
Exactly the point that I raise when I say:
Let’s say we find a bug in Customer handling. Is it in the controller or in the model class, or in some kind of “repository” or “view model” class where the business logic is stored? You’ll end up with database logic in the controller class and business logic in there too, so it could be anywhere. When you look at the directory tree in that MVC structure, the repository, the controller and the model are all in different places in the tree. Everyone knows that any developer is going to spend 90% of their bug fixing time just finding the bug, only 10% of the time fixing it. So you’ve made the job of finding the bug much harder.
The article is actually a pretty good introduction to domain modelling without discussing domain modelling, but that’s another story for another day.
[7] Domain-Driven Design: Effective Domain Modeling and its Perks
In this article, we will attempt to compare DDD with the traditional and commonly used layered architecture that is prone to anemic domain models. We will also list some key characteristics that the domain model should have — should you choose to employ DDD — as well as discuss the business value that DDD can bring to your organization.
This is more of a comparison of a domain modelled architecture vs a layered architecture but most of the arguments that it makes apply to comparison of domamin modelled architecture vs MVC as well. In this article as well as his prior article, Pablo Martinez gives a good hands-on explanation of building a system using domain driven design (DDD).