Architecture

MVC is not that bad !

I’ve heard many people say that MVC is a bad architectural pattern and you should never use it in production, they will immediately ask you why do you use it instead of others patterns such as MVVM or MVP and they might ask you to change. But in this article I want to make some points to prove that MVC is not that bad and it even very useful in many cases. Let’s go straight into the post.

1. If MVC is Massive View Controller it is because of you.

If you ask developers on how they design their app many people will answer you that they use MVC, MVVM or MVP, that means they consider those design patterns are the design of the whole application. But I could tell you that it’s a wrong answer and prove that they don’t really know how to design an application because MVC, MVVM or MVP are just UI architectural design patterns they doesn’t include navigating, networking, databases,… So they can’t represent for the who application design. If you only use one of those patterns you will end up with a massive application architecture which contains many complex components doing too much regardless if you’re MVC or other patterns. In contrast, if you have a good knowledge of how to separate responsibilities, split business logic from UI, develop separated modules you can end up with a very clean application with MVC. The MVC itself also has many ways to implement, you can split a controller into many smaller MVCs when needed to make your code cleaner and easier to add more features.

You can take a look at the following video to understand more about those design patterns:

2. MVC is great for small application.

Let’s take a look at MVC and MVVM events flow:

MVC
MVVM

What’s the difference ? That is the View Model in MVVM doesn’t talk directly to the View as the Controller in MVC does. That means the View Model can be platform-agnostic which doesn’t depend on any specific-platform such as iOS so that be reused in other any platforms such as iPadOS, macOS,… In addition, the View Model also take responsibility of transform data from other components to representable data for the View, so the View can use that data to present to the user. That’s great ! Yes, but in a case of simple application that doesn’t have complex representation logic and also doesn’t need to be reused those logic, you can definitely use MVC. Unlike MVVM, you usually see that the Controller or the View need to take responsibility of transform data to representable data for the View but it can be acceptable in a simple application with a good MVC implementation. Beside that, MVC is also more simpler to implement so it’s easier for less experience developers in the team to understand the project they’re working on.

3. MVC is great for initial states of the development process.

Development is a long finite process combined by many short processes (sprints if you follow Agile). To achieve a short process you need a fast, suitable and sustainable solution to make you app always available to be shipped. So that using MVC and having automated testing to back it up is very efficient solution to do it. For me, I always try to follow TDD process to develop features, and I usually start with MVC pattern when develop Presentation Layer for my app. So that when few short process passed and the app getting more complicated, having tests help me refactor the code from MVC to MVVM or MVP easily because if there’s any breaking changes there tests will notify me.

Conclusion

MVC, MVVM or MVP are design patterns, neither better or worse than the other, they are just different approaches, it depends on what you need and how abstraction do you want in your application. There’s nothing wrong if you want to use MVC and in this article I showed three main reasons why. Remember, If you aren’t disciplined the code will be a mess no matter which pattern you use ! I hope you got something home after this post. I would like to hear your story about the topic so feel free to comment to the comment section bellow.

Thanks for reading. See you in the next post.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *