3

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

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

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

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

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

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

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

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

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

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

  2. 逻辑呢，如果获取客户端对象中有一些逻辑验证（可能不是最好的例子，但希望它能够理解这一点）。

编辑：

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

4

1 回答 1

4

好吧，这是我对您的设计的评论：

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

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

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

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

祝你好运！

更新

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

I'm a believer of keeping things simple and following YAGNI. Don't make an interface until there are more than two classes that are going to implement/already implementing that interface (the DAL is always an exception to this though).

于 2009-04-18T13:33:35.800 回答