Onion architecture vs 3 layered architecture

Question

I see only benefits to the onion architecture over the 3 layered architecture where the BL had responsibility to call methods on DAL (or an interface of DAL) to do CRUD. The onion has better separation of concerns, testability, maintainability and is cleaner.

So is the onion architecture indeed better in all aspects and 3 layered architecture is just an old way of doing things, or there are some scenarios where I should prefer to use the 3 layered architecture, if so - which?

Answer 1

Layers, Onions, Ports, Adapters: it's all the same

Since this article makes clear that onion is equivalent to 3 layer + application of the Dependency Inversion Principle (DIP), then the question becomes "where should I prefer to use DIP?" I'd say any non-toy project. Using DIP allows the core of your code to be more isolated, testable and maintainable. When you really don't care about that is when it's a throw-away project or when you are trading maintainability for performance.

Also, don't confuse DIP with DI (Dependency Injection) containers. One doesn't imply the other.

Answer 2

I don't think the accepted answer gives a full picture, these principles are very similar but differ a bit in approach and philosophy.

TL;DR

Onion: Domain model is correct, data reflects domain model.

Layered: Data is correct, domain model reflects data.

Onion

Onion puts the Domain Model, such as POJO and rich domain classes at the center of the application where persistence is a plugin to the application.

#Example
You have an Order with Items. You add the item to the order
object itself then persist it with a tool.

var order = yourOrder;
// assigns the order id or uses maybe an ORM to handle it
order.AddItem(item); Orders.Update(order);

Layered

Layered puts the data itself in the center. The data is then interacted through the domain model to get a rich representation of the data.

#Example
Order has items.
To add item to Order you add an Item with reference to the Order.
To get the updated order you can reload the order with the items to get the updated version of the data according to the DB.

OrderItems.Create(itemWithOrderId);
Order = Orders.Read(orderId, { withItems = true })

Common features

UI, API, authentication, services and use cases are the same in both. The outside interacting with the application is the exact same.

Considerations

Not to say that the DB should decide how the application should look like but I feel like Onion is more suited towards document databases like MongoDB since you don't need complex mapping, persisting etc. If you have an SQL DB I would rather like to say "insert into Table ..." and assume the data is correct because of a strongly enforced schema.