5

我正在构建一个具有表示层 (PL)、业务逻辑层 (BLL) 和数据访问层 (DAL) 的 3 层架构。
传统的 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 参考（用于具体类型的 DI 到 BLL 对象的构造函数）
  • BLL 项目 -> 无参考
  • DAL 项目 -> BLL DLL 参考（用于实现 BLL 接口）

那么国际奥委会和传统的3层冲突吗？

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

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

你怎么做到这一点 ？

4

1 回答 1

2

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

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

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

  • PL => 对 BLL 和 DAL（具体和接口）以及 IoC 容器的引用
  • BLL 引用 DAL（或只是接口，如果适用）
  • DAL 无依赖（虽然通常会对 DTO / POCO / 实体有依赖）

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

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

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

于 2012-07-05T05:50:45.423 回答