Why you should adapt onion architecture in your C# applications
By: Abdullahi Yusuf
Tags: Dot Net Framework, Mvc Frameworks, Onionarchitecture, C Sharp Programming

Introduction

The Onion Architecture term was coined by Jeffrey Palermo in 2008. This architecture provides a better way to build applications for better testability, maintainability, and dependability on the infrastructures like databases and services. This architecture’s main aim is to address the challenges faced with 3-tier architecture or n-tier architecture and to provide a solution for common problems, like coupling and separation of concerns. There are two types of coupling — tight coupling and loose coupling.

Tight Coupling

When a class is dependent on a concrete dependency, it is said to be tightly coupled to that class. A tightly coupled object is dependent on another object; that means changing one object in a tightly coupled application, often requires changes to a number of other objects. It is not difficult when an application is small but in an enterprise-level application, it is too difficult to make the changes.

Loose Coupling

It means two objects are independent and an object can use another object without being dependent on it. It is a design goal that seeks to reduce the interdependencies among components of a system with the goal of reducing the risk that changes in one component will require changes in any other component.

The Onion Architecture

The idea of the Onion Architecture is to place the Domain and Services Layers at the center of your application. And externalize the Presentation and Infrastructure.

Onion Architecture Layers

This architecture relies heavily on the Dependency Inversion Principle. The UI communicates to business logic through interfaces. It has four main layers, as shown in figure 1.

Domain Layer Repository/Data Layer Service Layer Presentation/UI (Web/Unit Test) Layer

Figure 1

These layers are towards to center. The center part is the Domain entities that represent the business and behavior objects. These layers can vary but the domain entities layer is always part of the center. The other layer defines more behavior of an object. Let’s see each layer one by one.

Domain Layer

It is the center part of the architecture. It holds all application domain objects. If an application is developed with the ORM entity framework then this layer holds POCO classes (Code First) or Edmx (Database First) with entities. These domain entities don’t have any dependencies.

Repository Layer

The layer is intended to create an abstraction layer between the Domain entities layer and the Business Logic layer of an application. It is a data access pattern that prompts a more loosely coupled approach to data access. We create a generic repository, which queries the data source for the data, maps the data from the data source to a business entity, and persists changes in the business entity to the data source.

Service Layer

The layer holds interfaces which are used to communicate between the UI layer and repository layer. It holds business logic for an entity so it’s called the business logic layer as well.

UI Layer

It’s the most external layer. It could be the web application, Web API, or Unit Test project. This layer has an implementation of the Dependency Inversion Principle so that the application builds a loosely coupled application. It communicates to the internal layer via interfaces.

Advantages of Onion Architecture

There are several advantages of the Onion Architecture, as listed below.

It provides better maintainability as all the codes depend on layers or the center. It provides better testability as the unit test can be created for separate layers without an effect of other modules of the application. It develops a loosely coupled application as the outer layer of the application always communicates with the inner layer via interfaces. Any concrete implantation would be provided to the application at run time Domain entities are core and center part. It can have access to both the database and UI layers. The internal layers never depend on the external layer. The code that may have changed should be part of an external layer.

Why Onion Architecture

There are several traditional architectures, like 3-tier architecture and n-tier architecture, all having their own pros and cons. All these traditional architectures have some fundamental issues, such as — tight coupling and separation of concerns. The Model-View-Controller is the most commonly used web application architecture, these days. It solves the problem of separation of concern as there is a separation between UI, business logic, and data access logic. The View is used to design the user interface. The Model is used to pass the data between View and Controller on which the business logic performs any operations. The Controller is used to handle the web request by action methods and returns View accordingly. Hence, it solves the problem of separation of concern while the Controller is still used to database access logic. In essence, MVC solves the separation of concern issue but the tight coupling issue still remains.

On the other hand, Onion Architecture addresses both the separation of concern and tight coupling issues. The overall philosophy of the Onion Architecture is to keep the business logic, data access logic, and model in the middle of the application and push the dependencies as far outward as possible means all coupling towards to center.

Conclusion

Onion Architecture builds on the Ports & Adapters Architecture to add some internal organisation to the business logic of the application based on a few Domain Driven Design concepts.