What is wrong with a standard MVC project?

I am discussing the architecture for a new project with some colleagues. The project is relatively small and can be considered as a ‘normal’ crud web application.

Everybody has come up with an architecture where they are comfortable with. For example the onion architecture and the Domain Driven Architecture. Some programmers are having many years of experience, others (like me) only a few years.

I (almost fully) understand the concept of SOLID and SoC, but after hearing all the arguments of everyone, the confusing of how to use the suggested architectures and the different level of the developers, my question is very simple:

What is wrong with a standard MVC project compared to, in case, an onion architecture? In other words: why carrying a 40kg backpack if (you think) you only need a pair of shoes?

*What I consider as ‘standard’ is a solution with 2 projects:

  • A default Visual Studio asp mvc project (optional)
  • A project with a
    repository and the models (edmx)


Both Onion Architecture and MVC have their benefits and consequences.

No architecture is perfect and each was designed for a different purpose. Don’t build a huge truck if you only need a scooter, but don’t expect to transport 5 tons of boxes with a scooter.

MVC is works well in larger applications so that the FE developers can focus on the View and the BE developers on the controllers and model. The models can also mimic what is stored in the database which makes it easier for the DBA’s to implement. There are many more advantages of MVC which I am not going into detail now.

However splitting it up has an initial cost to set up and might not be worth it for a very small project.

The Onion Architecture has the benefit that is it relatively quick to set up so that you will see results (prototypes) much faster. Each layer depends on the inner layers but not the other way around. This gives you a lot of flexibility if you have to work on the entire scope anyway from user interface to domain models. I think this should work well for a small team, but I will not recommend it for a large team or a big project.

The Onion Architecture has a common set of domain models and services which are used by external “services” so that you can quickly add more “services” when required. However, you if you change the core of the “onion” you have to change the entire application as everything could potentially depend and use the core services and I think that is possibly the biggest drawback, but it might be okay if the project is very small.

Nothing, if the purpose is to follow it using a 3-tier design pattern. A lot of what is handle with MVC is with the View (UI), Controller (Business Logic), and Model (Data). I believe the Model and Controller are interchangeable for their purposes.

Essentially, the model handles your data layer, the view handles your presentation layer, and the controller can handle your business layer. Typically, if this is followed, separation of concerns is also taken care of. I think if any problem there is with the MVC standard, is that it quickly becomes tightly-coupled or not scalable if other layers are added without consideration to the three main layers that come with MVC.

The standard stated above does not account for business logic, UI logic, as separate layers at first glance. Though, this seemingly is taking care of by the first project, while the project with the models considers the data layer.


I see Onion as a good complement to MVC, and DDD… They are not in conflict, and in my mind, they don’t add extra over-whole to your project. A project that just uses MVC can be tightly coupled, onion architecture addresses this issue. And the same MVC project can have a messy model, which DDD would address.

Following these principles is not as important as understanding them. If you and your team understands them, then you know when it fits to implement them. Often you don’t need a strict implementation.

In my experience, when you blindly focus on principles, you forget about KISS.

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 *