我有一个CRUD密集的ASP.NET应用程序，其中包含存储过程中的所有业务逻辑。
作为一个例子，有一个UPDATE存储过程，它长约500行，包含大量条件逻辑，引用多个表和UDF的。 proc接受更新的字段名称和新值，设置一堆声明的变量，执行一堆验证并创建动态SQL语句来执行更新。一旦尺寸适合所有。它很大而且令人困惑。
我想将业务逻辑移到.NET端，以便更容易管理/更新，测试和置于源代码管理之下。
我的问题是：这个业务逻辑应该放在哪里？
假设我有一个带有名为“Factory”的属性的PurchaseOrder对象。如果工厂发生变更，我需要确保分配的新工厂生产的产品在PurchaseOrder上，它有定价，并且根据该工厂要求的最小数量等等。所有这些验证都需要在数据库中。
我是否应该让PurchaseOrder对象的Factory setter负责通过'isFactoryValid'方法/属性进行数据验证，该方法/属性对通用数据访问对象进行多次调用，然后进行更新（如果是）？
或者我是否创建了一个PurchaseOrder / Database'代理'对象，该对象负责处理与PurchaseOrder相关的数据访问。在这种情况下，我是否会在代理中使用'isFactoryValid'方法，该方法由PurchaseOrder的setter调用，然后调用代理的更新方法？
如何通过所有这些额外调用确定是否需要担心增加数据库的流量？
答案 0 :(得分：2)
一种方法： 您在.net（一个或多个数据类）中有一个数据层，其中包含该层的接口...然后您有一个业务层，使用该接口执行业务逻辑。 http://en.wikipedia.org/wiki/Multitier_architecture
答案 1 :(得分：1)
有两种主要模式被广泛用于实现DB中的持久性逻辑：
两个对象的技巧是知道何时去数据库并知道何时不。例如，将是在DB和域层之间进行的冗余验证，例如，甚至在进行DB调用之前，您应该评估非空值，将字符串截断为长度等等。只有在进行了这些检查后，才能调用数据库中的保存。
还有一系列策略可用于提高性能或最大限度地减少数据库跳闸，例如延迟加载，事务等。
答案 2 :(得分：0)
您还可以将业务逻辑转换为可重用Web服务的块。 WCF提供了出色的工具支持。
答案 3 :(得分：0)
了解域驱动设计（DDD），它将回答您的一些问题。它讨论了数据访问的存储库和验证规范。一个好的ORM也会有所帮助。这本书也很棒：
alt text http://img117.imageshack.us/img117/5282/032112521501aa240sclzzzzzzzv38088225zh7.jpg
答案 4 :(得分：0)
这取决于您创建的对象模型以及您如何让调用者决定哪个Factory将成为处理PurchaseOrder的新工厂。
例如，如果您向调用者提供他们可以选择的工厂列表，您可以将列表过滤为仅支持与现有PurchaseOrder关联的产品的那些（我假设您已编辑现有订单） 。如果你想让PurchaseOrder验证Factory可以处理订单，我会让PurchaseOrder上的setter调用Factory上的方法（比如CanProcessOrderFor（product，quantity））。
我假设您已经不得不进行数据库查询以获取工厂和PurchaseOrder列表。我会查询Factory对象返回他们支持的产品列表和当前数量（或最小订单 - 无论您的逻辑需要什么）。
如果这是常见的情况，像NHibernate这样的好的ORM会让你缓存其中一些结果以最小化往返。
