设计问题-使用c#更新多行-关注多个往返性能

我有一个现有的网站（基于.NET1.1），它调用web服务（基于.NET1.1）来访问数据。web服务调用存储过程来运行SQL

我有一个包含多个子对象（注释）（5-25）的父对象（字母），我需要将每个子对象上的一列更新为新值-在注释上设置一个标志以将状态设置为已批准-例如，此属性位于注释上，而不是字母上，因为以后可以添加更多未批准的注释

我们通常采用的方法是创建一个新的webmethod，例如ApproveComments并传入leteID，将当前在信函上的所有评论设置为approved。然后调用ApproveCommentsOnLetter存储过程将ApprovedFlag更新为True，其中letterID=传入的参数

这种方法意味着，随着时间的推移，随着新功能添加到系统的特定区域，我们往往会得到大量非常特定的Web服务调用和非常特定的存储过程。这是可行的，但这意味着我们总是在编写新的代码，我在考虑如何以不同的方式处理问题。我无法更改.net版本，因为目前这只是一个小小的更改，但随着时间的推移，我们将继续更新此应用程序，我正在考虑如何以不同的方式处理问题

我的想法是创建一个更通用的webmethod，名为UpdateComments，用于所有注释更新。我会将一个Comments对象数组传递给这个对象，它将具有get/set属性。在本例中，我将循环遍历每个列，并在将它们发送到web方法之前将其Status属性更新为True，但在将来，可以以类似的方式设置其他列，从而避免创建新的web方法

然后，我在数据库部分遇到了一些问题。感觉下一步将是拥有一个UpdateComment存储过程。然后，我不得不多次调用此功能，每次更新评论一次。我担心为这些电话（目前为5-25个）多次重复访问数据库不是很有效，只是感觉很糟糕。尽管我看到的另一种方法是，这些“批量”更新可以返回到一个特定的web方法和存储过程，专门用于一次更新给定的属性，但随后我又回到了我开始为我们添加到前端的每个新功能创建新的web方法和存储过程的地方

如果您能想到如何实现这一点，我将不胜感激——我不能去添加ORM/新版本的.net/等等。因此，我需要考虑如何在我已经使用的技术范围内实现这一点

下一步是创建一个UpdateComment存储过程。那我就得打好几次电话了

仅此而已——数据库不处理行集合，而Web服务主要关注行集合

如果您可以从存储过程移动到应用程序控制的数据修改，那么就没有什么可以说明您不能将多个update语句打包到SqlCommand的文本中

---

或者，如果这不是一个选项，也没有任何东西表明您不能在一次往返中多次调用存储的进程。

@Durator

如果我是你，我会继续对web服务进行特定调用，而不是尝试进行一般类型的调用。这可能是一点工作，但从长远来看，它是值得的，因为系统更易于维护，事实上，您已经提供了一个以业务为中心的抽象层。也就是说，从业务流程的角度来看，流程是批准给定信函的评论。一个具体的方法可以使它非常清晰，并映射到业务流程

现在就多次往返而言。。。 您的web服务可以接受注释id数组和字母id。这样，您就可以通过包含字母id和需要更新的注释id数组的连线进行一次调用

可以通过几种方式实现这一目标。 1.将存储的进程发送到sp中以逗号分隔的ID数组，然后拆分ID并进行更新

---

如果您使用的是MS SQL server 2008，则有一种称为TableValueParameter或TVP的新变量类型。基本上，您可以向storped proc发送一个.NET数据表，其中包含要发送的记录（列和行），并在SP中将参数视为“表”因此，您可以使用它进行连接，并使用它进行更新。

乍一看，每行打一个电话似乎不是正确的方法，但我建议您试试看。这当然是最简单的，您可能会发现，一旦投入生产，就不会出现用户感知的性能问题

“或者，如果这不是一个选项，那么没有什么可以说明您不能在一次往返中多次调用存储的proc。”-我的开发伙伴们担心，平均每个用户操作调用同一个proc 5次（可能最多25次），a）对性能不利，b）只是不好。我没有任何一种方法的性能数据可供备份（因为我还没有构建它），因此我想知道这是“过早优化”还是这种方法的一个重大问题。往返多次肯定会有性能差异。当使用一条语句时，使用多条update语句也有（较小的）性能差异。是否为时尚早实际上取决于应用程序：对于许多应用程序来说，25次往返可能还可以；对于大多数应用程序来说，50000次往返可能并不合适。任何没有测量的优化在技术上都是不成熟的。