N 层架构设计关注点分离

Question

我意识到已经有很多关于 n 层设计的帖子，这可能是我在思考问题并绕圈子，但我现在自己都感到困惑，想从社区中得到一些澄清请。

我正在尝试将我创建的项目（并且一开始在架构上的设计不是很好）分成不同的层（每个层都在自己的项目中）：

• 用户界面
• 业务对象
• 逻辑/业务
• DAL

UI 应该只调用逻辑层来获取它的东西

业务对象不应调用或引用其他任何东西，只是作为存储数据的一种方式

Logic / BUSINESS 层应包含系统中获取、创建、更新、删除 (CRUD) 对象的所有方法，并且对BO 和 DAL。它将业务逻辑应用于操作，然后将实际的 CRUD 委托给 DAL。

DAL 只会对数据库执行 CRUD 操作。它会引用 BO，因为它会为 Get 等返回它们。

我的问题是逻辑类是否应该只调用其等效的 DAL 类而只调用逻辑类？换句话说，CompanyLogic 类应该只调用CompanyDAL 类。因此，如果它想通过 ID 获取客户端对象，它将调用 ClientLogic.GetClientByID(int) 而不是 ClientDAL.GetClientByID(int)。

我认为它可能应该留在自己的层上的原因是：

1. 这似乎会放松项目之间的耦合

2. 如果获取客户端对象在其中包含一些逻辑验证，那么逻辑呢（可能不是最好的示例，但希望它能够理解重点）。

编辑：

我不确定这是否是我的糟糕设计，但目前业务层有许多类，包括 ClientBULL 和 CompnayBULL，这两个类相互调用。我为每个类使用一个接口，并有一个工厂来构建对象以尝试减少任何耦合，但由于在两个类中调用方法，它们现在不能没有彼此而存在。这是一个坏主意吗？

Answer 1

嗯，这是我在你的设计上的 cmets：

• 逻辑对于本质上是分配给抽象持久性的层来说是个坏名字。我可能会称它为“存储库”或“持久性”或 DAO（数据访问对象）而不是“逻辑”，这是模棱两可的，可能绝对意味着 任何东西。

• 如果您真的想将业务层与 DAL 分离，您的逻辑层应该只接受 DAL 的接口，而不是具体的 DAL 类。

• 关于验证的位置有两种观点。有些完全可以在 UI 层进行验证；其他人宁愿抛出异常或从业务层传递消息。不管你走哪条路，只要保持一致，不要在多个地方重复验证，你会没事的。

• 继续尝试编码可能是我能给你的最好建议。仔细考虑它很好，但在某一时刻，你需要在编码时看到它，只有这样，微妙的怪癖和陷阱才会暴露出来。不管你能想出什么原型，肯定会对你的开发和设计方向有价值。

祝你好运！

更新

重新编辑：在同一个命名空间或程序集中，对具体类的调用绝对没问题。我认为你需要为业务逻辑设置接口会过于复杂——我的意思是你应该遵循的规则不止一套吗？

我坚信保持简单并关注YAGNI。在有两个以上的类将要实现/已经实现该接口之前不要创建接口（尽管 DAL 始终是一个例外）。