.net - 将业务逻辑移出数据库时将其移至何处

Question

我有一个 CRUD-heavy ASP.NET 应用程序，其中包含存储过程中的所有业务逻辑。

例如，有一个约 500 行长的 UPDATE 存储过程，包含大量条件逻辑，引用多个表和 UDF。 proc 接收正在更新的字段名称和新值，设置一堆声明的变量，进行一堆验证并创建一个动态 SQL 语句来进行更新。一旦尺寸适合所有。它很大而且很困惑。

我想将业务逻辑转移到 .NET 端，以便更轻松地管理/更新、测试和置于源代码控制之下。

我的问题是:这个业务逻辑应该去哪里？

假设我有一个名为“Factory”的属性的 PurchaseOrder 对象。如果工厂发生变化，我需要确保分配的新工厂生产在 PurchaseOrder 上的产品，它有定价，并且有基于该工厂的最小数量要求等。所有这些验证都需要在数据库。

我是否应该让 PurchaseOrder 对象的 Factory setter 负责通过“isFactoryValid”方法/属性进行数据验证，该方法/属性对通用数据访问对象进行多次调用，然后进行更新(如果是)？

或者我是否创建了一个 PurchaseOrder/Database 'proxy' 对象，它只负责处理与 PurchaseOrder 相关的数据访问。在这种情况下，我是否会在由 PurchaseOrder 的 setter 调用的代理中拥有一个“isFactoryValid”方法，然后再调用代理的更新方法？

我如何确定是否需要担心所有这些额外调用会增加数据库的流量？

Answer 1

有两种主要模式被广泛用于在数据库之外实现持久化逻辑:

ActiveRecord Pattern - 持久性逻辑在您的域对象中。

Repository Pattern - 一个单独的对象或层处理数据访问——您的“代理”概念解决了这个问题。

这两个对象的诀窍是知道什么时候去数据库，什么时候不去。例如，将在 DB 和域层之间进行冗余验证，例如，即使在您进行 DB 调用之前，您也应该评估非空值、将字符串截断为长度等。只有在这些检查完成之后应该在数据库中调用 Save 。

还有多种策略可用于提高性能或最大程度地减少数据库访问次数，例如延迟加载、事务等。