2

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

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

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

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

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

我是否应该让 PurchaseOrder 对象的工厂设置器负责通过“isFactoryValid”方法/属性进行数据验证，该方法/属性对通用数据访问对象进行多次调用，然后进行更新（如果是）？

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

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

4

5 回答 5

2

一种方法： 您在.net 中有一个数据层（一个或多个数据类），该层有一个接口......然后您有一个使用该接口执行业务逻辑的业务层。http://en.wikipedia.org/wiki/Multitier_architecture

于 2009-04-22T00:37:11.063 回答
1

有两种主要模式被广泛用于在 DB 之外实现持久性逻辑：

  • ActiveRecord 模式- 持久性逻辑在您的域对象中。
  • 存储库模式——一个单独的对象或层处理数据访问——你的“代理”概念解决了这个问题。

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

还有多种策略可用于提高性能或最小化数据库访问，例如延迟加载、事务等。

于 2009-04-22T00:43:11.283 回答
0

您还可以将业务逻辑转换为可重用的 Web 服务块。WCF 提供了很好的工具支持。

于 2009-04-22T00:39:57.593 回答
0

研究领域驱动设计 (DDD)，它将回答您的许多问题。它讨论了用于数据访问的存储库和用于验证的规范。一个好的 ORM 也会有所帮助。这本书也很棒：

替代文字 http://img117.imageshack.us/img117/5282/032112521501aa240sclzzzzzzzv38088225zh7.jpg

于 2009-04-22T00:49:05.510 回答
0

这将取决于您创建的对象模型以及您如何让调用者决定哪个工厂将是新工厂来处理 PurchaseOrder。

例如，如果您给调用者一个他们可以从中挑选的工厂列表，您可以将该列表过滤为仅支持与现有 PurchaseOrder 关联的产品的那些工厂（我假设您正在编辑现有订单）。如果您想让 PurchaseOrder 验证 Factory 可以处理订单，我会让 PurchaseOrder 上的设置器调用 Factory 上的方法（类似于 CanProcessOrderFor(product, quantity)）。

我假设您必须已经进行数据库查询才能获取工厂列表和采购订单。我会让工厂对象的查询返回他们支持的产品列表和当前数量（或最小订单——无论你的逻辑需要是什么）。

如果这是一个常见的场景，像 NHibernate 这样好的 ORM 可以让你缓存其中的一些结果以最小化往返。

于 2009-04-23T03:17:25.037 回答