.net 理解洋葱和N层体系结构之间的差异

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


它看起来像一个N层架构。如果我引入接口，它是否可以与洋葱架构相媲美。
如何将其转换为ONION体系结构而不影响安全性、可伸缩性和性能。

---

洋葱架构本质上是一种利用依赖注入的n-teired架构。例如，考虑一个应用程序，它需要一些数字，添加它们并显示结果。 N分层：

数据访问层：

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

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

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

Gui层：

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

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 class SqlNumbersGetter
{
    public List<int> GetNumbers() => ...
}

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

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

Gui层：

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

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

---

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

它是一个良好的体系结构，遵循坚实的原则：

• 每个部分都有各自的责任，将因相同原因而发生变化的事物集中在一起。您希望将您的模块从整个组织的复杂性中分离出来，并设计您的系统，使每个模块只负责（响应）该业务职能的需要
• O笔闭合原则：编程到接口，以便您可以更改实际实现，而不会对客户端模块产生连锁反应”

“当有新需求时，您可以在不修改任何旧代码的情况下向该系统添加新功能。只需编写新代码即可添加这些功能。”Bob叔叔

• Liskov替换原则和I接口分离原则更适合于构建类的方式，简而言之：支持组合而不是继承，如果系统的组件只对类的方法子集感兴趣，则为该组件提供类包含的接口只调用它感兴趣的方法子集

• D依赖倒置原则：您的高级策略组件不应依赖于低级细节组件。接口应由高级组件决定，细节必须符合它。例如，您的核心层不应依赖于用户界面的实现，用户界面应uld取决于核心槽接口

在这里，您可以找到洋葱架构的详细说明： Victor Rentea-干净代码的艺术：

设计方案：

---

一些顽固的老前辈可能会发现很难将洋葱与尊重坚实原则的经典三层体系结构区分开来：）