将数据移出数据库时将业务逻辑移动到何处

我有一个CRUD沉重的ASP.NET应用程序，其中包含存储过程中的所有业务逻辑。将数据移出数据库时将业务逻辑移动到何处

作为一个例子，有一个UPDATE存储过程约500行，并包含大量的条件逻辑，引用了多个表UDFs & UDF。 proc需要更新字段名称和新值，设置一堆声明的变量，执行一堆验证并创建动态SQL语句来执行更新。一旦适合所有人。这很大，很混乱。

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

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

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

我应该有PurchaseOrder对象的Factory setter负责通过一个'isFactoryValid'方法/属性来进行数据验证，该方法/属性可以对通用数据访问对象进行多重调用，然后进行更新？

我还是创建一个PurchaseOrder /数据库'代理'对象，负责处理与PurchaseOrder相关的数据访问。在这种情况下，我是否会在代理中有一个'isFactoryValid'方法，由PurchaseOrder的setter调用，然后调用代理的更新方法？

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

来源

2009-04-22 GernBlandston

有迹象表明，被广泛用于实现持久性的逻辑出了DB的两个主要模式：

ActiveRecord Pattern - 持久逻辑是在你的域对象。
Repository Pattern - 单独的对象或图层处理数据访问 - 您的“代理”概念解决了这个问题。

的技巧与这两个对象是知道什么时候跑一趟到数据库，知道什么时候不。例如，将是将在数据库和域层之间完成的冗余验证，例如，甚至在进行数据库调用之前，您应该评估非空值，将字符串截短为长度等。只有在这些检查之后已经作出应该打电话给保存在数据库中。

还有一系列可用于提高性能或最小化数据库访问的策略，如延迟加载，事务处理等。

来源

2009-04-22 00:43:11

一种方式做到这一点： 你必须与该层的界面在.NET数据层（一个或多个数据类）...然后你有使用执行业务逻辑的业务层接口。 http://en.wikipedia.org/wiki/Multitier_architecture

来源

2009-04-22 00:37:11 jle

但是请注意：将业务逻辑移出数据库可能会导致数据库调用（“chattiness”）增加 – RobS 2009-04-22 00:59:21

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

来源

2009-04-22 00:39:57

看看领域驱动设计（DDD），它将回答你的几个问题。它讨论了用于数据访问的Repositoryies和用于验证的规范。一个好的ORM也会有所帮助。这本书也很大：

alt text http://img117.imageshack.us/img117/5282/032112521501aa240sclzzzzzzzv38088225zh7.jpg

来源

2009-04-22 00:49:05 NotDan

这将取决于你所创建的对象模型和你是如何让来电者决定哪些工厂将成为新工厂来处理PurchaseOrder的。例如，如果您为呼叫者提供他们可以从中挑选的工厂列表，则可以将列表筛选为仅支持与现有PurchaseOrder相关联的产品的列表（我假设您已编辑现有订单）。如果你想让PurchaseOrder验证Factory可以处理订单，我会让PurchaseOrder上的setter调用Factory上的一个方法（类似CanProcessOrderFor（product，quantity））。

我假设你将不得不做一个数据库查询已获得工厂和PurchaseOrder列表。我希望Factory对象的查询返回它们支持的产品和当前数量的列表（或最小订单 - 无论您的逻辑需要如何）。

如果这是一种常见的情况，像NHibernate这样的好的ORM会让你缓存一些结果以最小化往返。

来源

2009-04-23 03:17:25

将数据移出数据库时将业务逻辑移动到何处

回答

相关问题