n-tier-architecture - N层架构设计关注点分离

Question

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

我正在尝试将我创建的一个项目(一开始在架构上设计得不是很好)分成不同的层(每个层都在他们自己的项目中):

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

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

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

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

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

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

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

1. 这似乎松散了项目之间的耦合

2. 逻辑呢，如果获取的客户端对象中包含一些逻辑验证(可能不是最好的示例，但希望它能说明问题)。

编辑:

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

Answer 1

那么，这是我对您的设计的评论:

• 对于本质上分配给抽象持久性的层来说，逻辑是一个糟糕的名字。我可能会称它为“存储库”或“持久性”或 DAO(数据访问对象)而不是“逻辑”，这是模棱两可的，绝对可以任何。

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

• 关于验证应位于何处，存在两种思想流派。有些完全可以在 UI 层进行验证；其他人宁愿抛出异常或从业务层传递消息。无论采用哪种方式，只要保持一致，不要在多个地方重复验证，就可以了。

• 继续尝试编码 可能是我能给你的最好建议。仔细考虑它很好，但在某一时刻，您需要在编写代码时查看它，只有到那时，微妙的怪癖和陷阱才会显露出来。无论您能想出什么原型(prototype)，都对您的开发和设计方向很有值(value)。

祝你好运!

更新

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

我相信保持简单并遵循 YAGNI .在有两个以上的类将要实现/已经实现该接口(interface)之前不要创建接口(interface)(尽管 DAL 始终是一个异常(exception))。