了解 ONION 和 N 层架构之间的区别答案

【问题标题】：Understanding the difference between ONION and N-Layered architecture了解 ONION 和 N 层架构之间的区别
【发布时间】：2019-04-27 06:35:24
【问题描述】：

我正在构建基于 .Net 的应用程序的结构。目前，我使用的是 MVC 5。以下是系统不同组件的详细信息。
1。 数据库 – 这是底层数据库，将包含数据
2。 OData API – 此 API 将与数据库交互并仅执行与数据库相关的操作 (CRUD)。我希望这个 API 成为访问和操作数据的唯一平台。它将提供通过不同方式（IQueryable、SQL 查询、存储过程）检索数据的功能。
3。 商业服务——它包括两件事。引擎和 API。引擎中将包含业务逻辑，其中可能包含业务规则，例如 WorkflowEngine 将处理所有工作流操作。驻留工作流操作 (CRUD Ops) 和非驻留工作流操作（提交、批准、发回）。 API 将在 UI 和 Engine 之间进行通信。然后引擎将运行业务逻辑并与 OData 通信。 BusinessAPI 将是专有 API，对这些 API 的访问将基于订阅（付费访问）。
4。 UI – 用户界面将基于 MVC，仅与业务 API 交互，并且只负责显示数据并将数据发送回 BusinessAPI。

看起来像N层架构。如果我引入接口，它是否可以与 ONION 架构相媲美。
如何在不影响安全性、可扩展性和性能的情况下将其转换为 ONION 架构。

【问题讨论】：

一些顽固的老前辈可能会发现很难将 ONION 与尊重 SOLID 原则的经典 3 层架构区分开 :)

标签： .net architecture software-design onion-architecture n-layer

【解决方案1】：

Onion 架构本质上是一个使用依赖注入的 n-teired 架构。例如，考虑一个应用程序，它需要一些数字，将它们相加并显示结果。

N 层：

数据访问层：

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

业务逻辑层：

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

界面层：

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

洋葱架构非常相似，但我们现在使用接口和依赖注入：

数据访问层：

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

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

业务逻辑层：

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

界面层：

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));
}

然后您将让您的应用程序实例化所有接口实例，并将它们全部链接起来

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

【讨论】：

【解决方案2】：

简而言之，Onion 架构可以帮助您构建一个松散的耦合系统，有点像插件系统。您在中心拥有业务逻辑、核心、其他所有内容（用户界面客户端、第三方库、数据库存储库等）都可以更改，而无需更改此核心层中的某些内容。

这是一个遵循SOLID原则的良好架构：

每个部分都有S单一责任，将因相同原因而发生变化的事物集中在一起。您希望将您的模块与整个组织的复杂性隔离开来，并设计您的系统，以便每个模块只负责（响应）一个业务功能的需求。
Open 封闭原则：编程到接口，这样你就可以改变实际的实现，而不会对客户端模块产生涟漪效应“

“当有新需求时，您可以向该系统添加新功能，而无需修改任何旧代码。这些功能将仅通过编写新代码来添加。”鲍伯叔叔

Liskov 替换原则和 I接口隔离原则更适用于您构造类的方式，简而言之：支持组合与继承，如果你系统的一个组件只对一个类的方法子集感兴趣，给那个组件一个只包含它感兴趣的方法子集的类的接口
D依赖倒置原则：您的高级策略组件不应依赖于低级详细组件。接口应该由高层组件决定，细节必须符合它。例如你的核心层不应该依赖于用户界面的实现，用户界面应该依赖于核心槽接口。

这里你可以找到洋葱架构的详细解释： Victor Rentea - 简洁代码的艺术： https://www.youtube.com/watch?v=c0L7EdsxQ_c

设计架构： onion architecture

【讨论】：