N层架构设计中的关注点分离

Question

我知道已经有很多关于n层设计的帖子了，这可能是我过度思考并陷入死结，但现在我自己都感到困惑了，希望从社区中获得一些明确的答案。我试图将我创建的项目（最初没有进行良好的架构设计）分成不同的层（每个层都在自己的项目中）：

UI

Business Objects

Logic / Business

DAL

UI应该只调用逻辑层来获取它的内容

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

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

DAL只需对数据库执行CRUD操作。它将引用BO，因为它将返回它们以供获取等操作使用。

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

我认为它应该保持在自己的层中的原因是：

它似乎会减少项目之间的耦合

如果逻辑中获取客户端对象时有一些逻辑验证（可能不是最好的例子，但希望能传达出点），那么怎么办？

编辑：

我不确定这是否是我的设计不好，但目前业务层有许多类，包括ClientBULL和CompnayBULL，两个类互相调用。我为每个类使用一个接口，并有一个工厂来构建对象，以尽量减少耦合，但由于在两个类中调用方法，它们现在无法独立存在。这是一个坏主意吗？

- Jon

Answer 1

好的，以下是我对你设计的评论：

• “Logic”这个名称不太合适，因为它本质上是一个分配给抽象持久性的层。我可能会称其为“Repository”、“Persistence”或“DAO”（数据访问对象），而不是“Logic”，因为后者含糊不清，可以绝对意味着任何事情。

• 如果您真的想将业务层与DAL解耦，则逻辑层应仅接受DAL的接口，而不是具体的DAL类。

• 关于验证应该位于哪里，有两种看法。有些人完全可以接受在UI层进行验证；其他人则更愿意从业务层抛出异常或传递消息。无论您选择哪种方式，只要保持一致，不要在多个地方重复验证，那么就没问题了。

• 放心尝试编码可能是我能给你的最好建议。思考是好的，但在编码时需要看到它，只有这样才能发现微妙的怪癖和陷阱。您可以想出的任何原型都一定对您的开发和设计方向有价值。

祝你好运！

更新

关于您的编辑：在同一命名空间或程序集内，调用具体类绝对没有问题。我认为你需要为业务逻辑设置接口会过于复杂 - 我的意思是，是否有多个规则集需要遵循？

我坚信保持简单并遵循YAGNI原则。除非有超过两个将实现/已经实现该接口的类（但DAL始终是例外），否则不要创建接口。

- Jon Limjap

---

完全同意接口。我已经尝试创建一个工厂来生产每个具体类型。我在实现中遇到了问题，但将其留到另一篇文章中讨论。关于标题“LOGIC”的观点很好，谢谢…… - Jon