【问题标题】:Did I implement Onion Architecture correct?我是否正确实施了洋葱架构?
【发布时间】:2014-04-25 18:08:43
【问题描述】:

这是我第一次尝试实现洋葱架构。

AppService -> folder for the abstractions for the entire Application
Business -> Business logic using the abstractions in the Core project
DataService -> folder for abstractions that are implemented in the DataAccess project
Model -> Entities used by the application
WebService -> folder for abstractions that are implemented in the WebAccess project
  1. 上面放置的文件夹是否正确?
  2. DependencyResolution 项目的位置是否在 Domain 文件夹中?
  3. 基础架构中的每个项目是否都应包含一个 DependencyRegistrar 文件,该文件将核心项目中的接口与它所包含的项目中的实现一起注册?
  4. WebApi项目是否应该放在Presentation->Api中?是演示文稿吗?
  5. 我应该将每个项目的所有单元测试都放在“Tests”文件夹中吗?

提前致谢。

【问题讨论】:

    标签: .net onion-architecture


    【解决方案1】:
    1. 您的文件夹结构通常看起来不错。就个人而言,我倾向于采用更加模块化的方法,您的核心项目中的文件夹实际上是我的单个项目,但这只是我的偏好。
    2. 依赖解析不是您领域的一部分,也不是真正的基础设施(至少在我看来)。它本身就是一个概念。
    3. DependencyRegistrars 似乎没有必要。将抽象映射到实现是依赖解析的责任。
    4. 我的第一反应是不会,但过去我做过单页应用程序,我在同一个项目中使用过 MVC 和 WebApi。因此,他们将一起成为客户。如果每个移动客户端都有自己的后端,我会将这些项目与客户端放在同一个文件夹中。否则,如果它们在多个不同的客户端之间共享,我会考虑将它们放入顶级“后端”或“服务”解决方案文件夹。
    5. 我认为让每个项目及其测试彼此相邻更有意义,因此从一个项目导航到另一个项目或反之亦然很容易(即不必上下滚动解决方案)。

    所以除了依赖解析住在域和DependencyRegistrars 之外,看起来还不错。具体细节取决于您认为最好的。

    【讨论】:

    • Onion 的所有图表都将依赖解析显示为最外层,因此 UI 不能依赖 DR。您的 UI 是否依赖于 DR?你是怎么解决的?
    • 基本上,我设计应用程序的方式是每个Composition Root 都应该有自己的引导程序,而引导程序又引用DR(很像this question 中描述的方式)。也许我对 DR 的理解与应有的略有不同,但它对我个人来说效果很好,同时与架构的核心理念(即外部化依赖项)保持兼容。
    • 谢谢,我接受了你的回答。但我无法使用 WebActivator 完成此操作。我的 UI 之一是 WPF 应用程序,我不知道在这种情况下如何将 DR 外部化而不直接在 WPF 应用程序中引用它。你能给我一个线索吗?
    • 所以你要做的就是让 UI 引用一个引导程序项目,该项目又引用 DR(UI > Bootstrapper > DR)。这与您对HttpApplication 所做的完全相同(Web Client > Bootstrapper > DR)。 WebActivator 所做的只是将方法连接到应用程序生命周期中的特定点。
    猜你喜欢
    • 1970-01-01
    • 2014-10-15
    • 2011-10-09
    • 1970-01-01
    • 2018-08-24
    • 2021-09-25
    • 1970-01-01
    • 2014-06-22
    • 2015-03-17
    相关资源
    最近更新 更多