Understanding the difference between ONION and N-Layered architecture

Question

I am making the structure of a .Net based application. For now, I am using MVC 5. Here are details of different components of the system.
1. Database – This is underlying database and will contain the data
2. OData API – This API will interact with database and will perform database related operations only (CRUD). I want this API to be only platform to access and manipulate data. It would provide the functionality to retrieve data through different means (IQueryable, SQL query, Stored Procedure).
3. Business Service – It would consist of two things. Engine and API. Engine would have business logic in it which could include business rules for example WorkflowEngine would handle all the workflow actions. Resident Workflow Action (CRUD Ops) and Non-Resident Workflow Actions (Submit, Approve, Send Back). API will communicate between UI and Engine. Engine will then run the business logic and will communicate with OData. BusinessAPIs will be proprietary APIs and access to these APIs will be subscription based (paid access).
4. UI – User interface will be MVC based and will only interact with Business APIs and will only responsible for displaying the data and sending the data back to BusinessAPIs.


It looks like an N-Layed architecture. If i introduce interfaces, would it be comparable to ONION Architecture.
How can i convert it to ONION Architecture without compromising the security, scalability and performance.

Answer 1

In short, Onion architecture help you to build a loose couple system, somehow like a plugin sys. You have in the center the Businesses logic, the core, everything else (User interface client, third party library, database repository and so on) could be change without the need to change something in this core layer.

It is a good architecture following the SOLID principles:

• each part has Single responsibility, gather together the things that change for the same reasons.You want to isolate your modules from the complexities of the organization as a whole, and design your systems such that each module is responsible (responds to) the needs of just that one business function.
• Open Closed Principle: programming to interface so that you can change the actual implementation without ripple effect for the client module "

“When there is a new requirement, you could add new features to that system without modifying any old code. The features would be added solely by writing new code.” Uncle Bob

• The Liskov Substitution Principle and Interface Segregation Principle it is more for the way you construct the classes, shortly: favor composition vs. inheritance and if a component of your system is only interested in a subset of the methods of a class, give that component an interface to the class containing only the subset of methods it is interested in

• Dependency Inversion Principle: Your high level policy components should not depend on low level detail components. The interface should be decided by the high level component and the detail has to conform to it.For example your core layer should not depend on the implementation of the user interface, the user interface should depend on the core trough interfaces.

Here you can find a detail explanation of the onion architecture: Victor Rentea - The Art Of Clean Code: https://www.youtube.com/watch?v=c0L7EdsxQ_c

The design schema: onion architecture

Answer 2

An Onion architecture is essentially an n-teired architecture utilising dependency injection. For example consider an application which takes some numbers, adds them and displays the result.

N tiered:

Data Access Layer:

public class SqlNumbersGetter
{
    public List<int> GetNumbers() => ...
}

Business Logic Layer:

public class Summer
{
    public int GetSum() => new SqlNumbersGetter().GetNumbers().Sum();
}

Gui Layer:

public class ConsoleDisplayer
{
    public void Display() => Console.WriteLine( new Summer().GetSum());
}

The onion architecture is very similar, but we now use interfaces and dependency injection:

Data Access Layer:

public interface INumbersGetter
{
     List<int> GetNumbers();
}

public class SqlNumbersGetter : INumbersGetter
{
    public List<int> GetNumbers() => ...
}

Business Logic Layer:

public interface ISummer
{
    int GetSum(INumbersGetter numberGetter);
}
public class Summer : ISummer
{
    public int GetSum(INumbersGetter numberGetter) => numberGetter.GetNumbers().Sum();
}

Gui Layer:

public interface IDisplayer
{
    public void Display(ISummer summer, INumbersGetter numberGetter)
}
public class ConsoleDisplayer : IDisplayer
{
    public void Display(ISummer summer, INumbersGetter numberGetter) => Console.WriteLine(summer.GetSum(numberGetter));
}

Then you would have your application instantiate all the instances of the interfaces, and link them all up

public void Main()
{
    new ConsoleDisplayer().Display(new Summer(), new SqlNumbersGetter());
}