洋葱建筑与六角形相比

Question

洋葱建筑与六角形相比

bor*_*ris 16 architecture software-design hexagonal-architecture onion-architecture

它们之间有什么区别(洋葱|六角形),从我的理解它们是相同的,它们关注的是应用程序核心的领域,应该是技术/框架不可知的.

它们之间有什么区别？

另外我认为使用一个优于另一个甚至是针对N层架构没有真正的优势,如果做得不好只是跟随其中任何一个都没有任何区别

使用一个优于另一个以及为什么要使用它有什么好处？什么时候用？

谢谢

Answer 1

cho*_*o70 23

它们之间有什么区别？

洋葱:有层,依赖关系始终指向内部,即层可以使用其中的任何层.内层是领域模型,外层是基础结构,但两者之间的层数可能不同.

六角形(它是原始名称"Ports&Adapters"的替代名称):没有图层.您有应用程序,端口和适配器.端口属于应用程序,它们是应用程序的API/SPI.适配器不在应用程序中,每个适配器都依赖于应用程序的端口.

一些人的讨论是,在实现六边形体系结构时,大多数人并没有将每个适配器放在一个工件中,而是将所有适配器放在一个工件中(如基础结构层).而且他们依赖整个应用程序的适配器,而不仅仅是他们使用的端口.事实上,这将是一个洋葱.

实现六边形右边应该将适配器彼此分开,并且每个适配器应该仅依赖于它使用/实现的端口(取决于端口是驱动器还是驱动器).

另一个区别是Hexagonal没有提到六边形内部结构(应用程序).

使用一个而不是另一个有什么好处？

六边形的好处在于它更模块化,您可以清楚地分离组件,防止代码泄漏.另一方面,洋葱在这个意义上更危险,因为您可以直接从UI访问数据库(它们都属于同一层).

洋葱的好处来自上述.由于六边形有很多工件,如果项目很大,整个项目的构建应该花费很多时间.

你为什么要用呢？什么时候用？

使用它们中的任何一个的关键是你专注于你试图解决的真正问题,而不使用任何技术或框架.该应用程序与技术无关,并且很容易从框架迁移到另一个框架.因此,它们都被称为"干净"的架构.您的应用程序核心没有框架代码,注释等.

那么......为什么要使用它们？

因为您提高了可维护性,可测试性,并且您拥有干净的代码.

什么时候使用它们？

我宁愿说什么时候不使用它们.如果您正在开发的应用程序并不复杂,例如它只是一个CRUD,也许它不值得使用它们.

就个人而言,我更喜欢"端口和适配器".

希望我的出路有所帮助.

所以它被称为洋葱，因为它是代码气味：D (5认同)
@choquero70 我认为说 UI 和数据库位于同一层与您在六边形中提到的错误相同，人们将所有内容都放在一个工件中。使用洋葱架构，您有层，但层可以进一步拆分，并且层内的一般规则是_不允许水平依赖关系_。 (4认同)
**另一方面，洋葱在这种情况下更加危险，因为您可以直接从UI访问例如数据库（它们都属于同一层）。**：此语句是不正确的。 (2认同)
就像@AmitJoshi menetioend一样，这样的说法“另一方面，洋葱更危险，因为例如可以直接从UI访问数据库（它们都属于同一层）**”是不正确。UI和数据库不应存在于同一层中！用户界面通常属于“应用程序”层，而数据库应位于“基础结构”层。 (2认同)
@wasyl我并不是说洋葱拱支持从UI访问数据库，我只是说您可以做到，因为它是一个分层的拱，并且两者都在同一层。从开发人员的角度出发，不应该这样做，但是架构允许这样做，因为它们位于同一层，并且洋葱拱形模式定义中没有任何地方禁止这样做。分层拱门的示例来源：O'Reilly Media的Mark Richards撰写的“ Software Architecture Patterns”一书，2015年2月。第1章，图1-4，https：//www.oreilly.com/library/view/software-architecture -patterns / 9781491971437 / ch01.html (2认同)
@choquero Onion Arch 是 PaA 的改编版。你有垂直和水平的分离。垂直是一种分层，其中外部单元依赖于内部单元，而内部单元对外部单元一无所知。巴勒莫图中显示的最外层的水平分离，其中您拥有 API、基础设施和所有其他实现单元，它们彼此之间也不了解任何信息，因为它们只能通过内层（主要是应用程序层）进行通信。例如，在 .NET 术语中，它们不会是同一程序集的一部分，也不会相互直接引用。 (2认同)
@choquero70 我读过它们。但是“一层的组件可以使用同一层的组件”和“洋葱拱形模式定义中没有任何地方说这是禁止的”实际上是错误的，因为巴勒莫断言所有耦合/依赖关系都朝向中心（即朝向更内部的）层）：“基本规则是所有代码都可以依赖于更中心的层，但代码不能依赖于离核心更远的层。换句话说，所有耦合都是朝向中心的。” https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/ (2认同)

Answer 2

STW*_*STW 19

以前的答案对洋葱架构做出了根本不正确的陈述。他们断言“在 Onion 中，UI 和数据访问是同一层的一部分”。混淆可能来自于认为所有层都在与它们上面和下面的一切对话。

实际上，洋葱图是洋葱架构的糟糕表现。关键要点是核心域层与任何周围层都不可知，并且周围层通常也彼此不可知。通常这意味着 UI 与 Service 对话，Service 与 Data 和 Domain 层对话。UI 不直接与其他层交互，层交互通过依赖注入和接口隔离进行抽象。

据我所知，没有任何架构模式建议混合数据访问和 UI（有些，例如Active Record，混合业务和数据访问）。另外，有一些技术可以生成避免层的代码——快速开发工具经常这样做，但这些工具有利于部署速度而不是设计和可维护性。

Onion、Hexagonal 和 Ports and Adapters 实际上都是同一个概念架构的不同名称。

Mark Seeman 发表了一篇很棒的文章，有助于阐明差异（如果有的话）是边际和语义的：层、洋葱、端口、适配器：都是一样的

他不提倡混合，但从技术上讲，因为两者都在同一层，你可以，虽然你不应该。不混合由程序员决定，但架构允许。 (2认同)

归档时间：	7 年，6 月前
查看次数：	5401 次
最近记录：	6 年，2 月前