【问题标题】：How to organize dependencies in 3-tier architecture如何在 3 层架构中组织依赖关系
【发布时间】：2015-01-09 18:05:51
【问题描述】：
我正在启动将使用 REST API 的 3 层架构的项目。
我想把每一层分成单独的模块，所以我肯定需要至少3个模块：
在它们之间建立依赖关系的最佳方法是什么：
1)
- REST 依赖于 BLL
- BLL 依赖于 DAL
- DAL 不依赖任何东西
2)
- REST 不依赖任何东西
- BLL 依赖于 REST
- DAL 依赖于 BLL
3)
- REST 依赖于 REST-BLL-Interfaces
- REST-BLL-Interfaces 不依赖任何东西
- BLL 依赖于 REST-BLL-Interfaces 和 DAL-BLL-Interfaces
- DAL-BLL-接口不依赖任何东西
- DAL 依赖于 DAL-BLL 接口
第三种方法似乎与依赖倒置原则最兼容，但需要更多模块。
您如何命名这两个附加模块？
【问题讨论】：
标签：
java
n-tier-architecture
3-tier
【解决方案1】：
我会将您的 BLL 代码保存在一个名为 Services 的项目中，将您的 DAL 代码保存在一个名为 Repositories 的项目中，并将您的接口和业务对象（或实体）保存在一个名为 Core 的项目中。
您的 REST 项目应仅引用核心（以及用于解决依赖关系的服务）。您专门为接口编程。正如您所说，您也可以在此处使用 DI 原则。
您的服务和存储库应仅依赖于 Core。这些具体的实现只需要实现 Core 接口并作用于 Core 实体。
这种方法不仅允许您使用 DI，而且还使测试变得更加容易。此外，您的任何应用程序都不会与您的具体外部依赖项（即特定的数据库实现）紧密耦合。这使您的整个应用程序更加灵活和可扩展。
旁注：我经常包含另一个名为 Infrastructure 的项目来处理横切关注点，例如日志记录。这些具体的类实现 Core 接口，就像我的存储库和服务一样，可以使用接口调用。
【解决方案2】：
您可以引入所有具有所有接口和域模型的所有通用的第四个模块，但这不会阻止 REST 直接调用 DAL（它至少会编译）。
我通常这样做或直接选择第一个选项，我不担心这一点，因为我指望我的其他同谋开发人员有一些架构分离感。我过去曾使用“架构”方面来防止层跳跃，但您必须在构建/IDE 中包含方面编译器支持才能做到这一点。