CRUD 操作是否应该始终通过 BO 进行？答案

【问题标题】：Should CRUD operation go always thru a BO?CRUD 操作是否应该始终通过 BO 进行？
【发布时间】：2010-02-19 11:34:33
【问题描述】：

我有一个这样的架构

存储库 -> BO -> WCF -> Web

和维卡诗句

存储库

我的问题是，如果我只有简单的 CRUD 操作，例如按其 ID 删除记录，是否可以跳过 BO 并直接进入存储库？

存储库

【问题讨论】：

标签： wcf architecture

【解决方案1】：

不，不可接受 - 总是走同一条路 :)

正如 Pontus 所说的那样——无论哪种方式都可以；但你必须选择一种方法并坚持下去；始终如一。如果你把两者混在一起，你几乎肯定会被咬。

至于选择哪一个 - 如果它满足您的需求，任何一个都可以，但需要注意的是知道哪些相关风险可能会长期困扰您。我几乎总是采用“BO”方法，因为开销不是很大，而且如果系统需求发生变化，您很可能会避免大量返工；长期使用 BO 肯定更安全。

【讨论】：

【解决方案2】：

答案是，就像在建筑中一样，“视情况而定”。只要您清楚何时允许什么，您就可以拥有允许或不允许绕过的架构层。

在您的情况下，您简化了基本的 CRUD 情况，这很好：传递 CRUD 的 BO 代码本身只是一个毫无意义的成本。但是您也引入了关于何时使用业务对象层的不确定性：在极端情况下，系统可能倾向于将所有内容都视为 CRUD，从而消除 BO 层的任何值。作为一个稍微不那么极端的情况，您可以获得一些实现复杂逻辑的 BO 函数，它们彼此解耦，并且业务域的任何面向对象表示。

只需清楚（并写下几句话记录）何时使用哪种模式的原则，并严格应用这些原则。

【讨论】：

【解决方案3】：

我的建议是坚持您的架构并通过 BO，更新或删除等特定操作可能需要业务规则验证和其他级联类型操作。您现在可能没有为实体定义任何业务规则，但您应该设计它以实现可扩展性。

在某些情况下，绕过您的 BO 进行读取/检索类型操作可能是可以接受的，例如检索某物或 DTO 对象的列表，这些对象合并了来自多个实体的信息以进行严格的展示、搜索或验证，以实现更好的简单性或性能改进在复杂的环境中。

【讨论】：

有时绕过会引入不一致，这将使您的代码更难调试和维护超时，并使应用程序的重组更加复杂（例如在抽象出数据访问时）。 BO 对性能的影响可能无关紧要。直接对数据层进行非 BO 类调用意味着它具有应该在 BO 层中的逻辑级别。