0

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)
Improve this question
5
  • Did someone say there was something wrong with it?
    – TZHX
    Commented Oct 4, 2016 at 18:36
  • 1
    Ask the people who have a problem with it. MVC is pretty common and a good solution in many cases. Nothing is good all the time just like most things are good some of the time. Plenty of resources on the internet about the pros and cons of certain strategies and when to apply them.
    – JeffO
    Commented Oct 4, 2016 at 18:40
  • @TZHX Good point! The question is more focussing on "why all the bells and whistles, if a standard project is also possible"
    – Citizen SP
    Commented Oct 4, 2016 at 18:40
  • Also, you can always expand MVC to use a more complex pattern as MVVM when you need it. Get things done, and get things done fast.
    – Machado
    Commented Oct 4, 2016 at 18:50
  • 1
    Possible duplicate of .NET MVC project architecture / layering
    – Greg Burghardt
    Commented Oct 4, 2016 at 23:47

3 Answers 3

Reset to default
6

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.

Improve this answer
2

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.

Improve this answer
2
  • 7
    The Business Layer generally resides in the Model, not the Controller. The Controller merely decides which methods on the Business Layer to call. In Jeffery Palermo's Onion Architecture, the View and Controller would take up the UI and Infrastructure elements, respectively. The remainder of the architecture would reside in the Model.
    – Robert Harvey
    Commented Oct 4, 2016 at 20:01
  • @RobertHarvey Thank you for the clarification Robert, I have seen or heard that they are interchangeable.
    – JDavila
    Commented Oct 4, 2016 at 20:20
2

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.