传统 3 层架构与带 IOC 的 3 层架构

Question

我正在构建一个 3 层架构，其中包含表示层 (PL)、业务逻辑层 (BLL) 和数据访问层 (DAL)。
传统的 3 层架构逻辑指出，BLL 应充当 PL 和 DAL 之间的中介。PL 甚至不应该知道数据库的存在，而 DAL 不应该知道 BLL 或 PL 的存在。

实施上述操作将在 3 个不同的物理项目之间创建以下依赖关系，如下所示

• PL 项目 -> BLL DLL 参考
• BLL 项目 -> DAL DLL 参考
• DAL 项目 -> 无参考

然而，通过在 BLL 中定义接口供 DAL 实现并通过构造函数注入使用 DI，在 BLL 和 DAL 之间应用 IOC 的概念将改变依赖关系，如下所示

• PL 项目 -> BLL DLL 参考、DAL DLL 参考（用于具体类型到 BLL 对象构造函数的 DI）
• BLL 项目 -> 无参考
• DAL 项目 -> BLL DLL 参考（用于 BLL 接口的实现）

那么IOC和传统的三层有冲突吗？

理想情况下，我希望实现以下目标，同时通过 DI 维持我的 IOC。

• PL 项目 -> BLL DLL 参考
• BLL 项目 -> 无参考
• DAL 项目 -> BLL DLL 参考
  

你怎么做到这一点 ？

Answer 1

首先，您可以考虑使用接口解耦层，并且接口可以分为单独的 dll。这样，每一层只依赖于下一层的接口。

我也不确定为什么需要从 DAL 耦合到 BLL？这是为了回电吗？不能用事件代替吗？

假设所有 3 层都在进程中运行，并假设您的 PL 是应用程序的“入口点”（组合根），在我看来，如果您使用 PL 中的引导代码分离出接口，则通常的依赖项是：

• PL => 对 BLL 和 DAL（具体和接口）以及 IoC 容器的引用
• BLL 引用 DAL（或仅接口，如果适用）
• DAL 无依赖关系（尽管通常会依赖于 DTO / POCO / 实体）

PL 可以将 IoC 配置卸载到 Bootstrapper dll，从而导致：

• PL => 对 BLL 接口和引导程序的引用
• Bootstrapper => 引用所有内容和 IoC 容器
• BLL => 参考 DAL 接口
• DAL => 无依赖关系（尽管通常会依赖于 DTO / POCO / 实体）

对于某些容器，您可以通过使用配置或约定来避免从引导程序引用所有 dll 的要求。但是，这些 dll 显然仍然需要与您的应用程序一起部署。