为C#定制批量SQL处理的定制方法值得吗？

我即将经历一个相当大的项目，如果它真的进行下去，我希望会有很多数据库调用不断进行。我想知道，如果不使用实体框架，而是创建一个大批量执行所有SQL操作的自定义方法，是否值得。与实体框架的正常使用相比，哪些因素会使批量处理的使用更理想/更高效？我非常感谢您提供有关这方面的任何资源。我可以看到很多问题，比如在更新之前或者在更新的时候试图读取一个值，当然，这里有很多方法，但是我想知道是否有一个资源概述了所有的利弊，所以我不必写下一个模型，来考虑所有可能的权衡。p>

---

编辑：好的，我意识到我没有给出太多细节。该项目是一个消息传递服务。当消息传入时，它们已经是加密的json字符串。这些json字符串将被写入数据库进行检索。如果您需要更多信息，请告诉我。

尝试通过ORM执行批量操作通常是个坏主意（尽管这取决于您所称的“批量”；50条记录-很好；50000条记录-麻烦）。它可以工作，事实上，在后台，EF支持进入数据库的批量操作，但主EF接口往往是基于对象的，这意味着您需要获取数据（以及任何必需的子数据），在本地对其进行变异，然后有一个跨将所有数据推回服务器的事务，可能涉及竞争条件（时间戳/版本冲突）等

---

注意，TSQL已经支持这一点，没有任何问题。它被称为：TSQL<代码>更新，

删除

，等等。好的一面是您不再编写面向对象的编译器检查代码。缺点是您不再编写面向对象的编译器检查代码：）

EF比ADO.NET慢，但明显的折衷是编程更简单，错误几率更低。你的选择

1） 将存储过程与EF一起使用。如果你走这条路，我喜欢使用数据库项目，这样当涉及到源代码控制时，存储过程和所有数据库组件都被视为一等公民（参见MSDN）

2） 在原始SQL或存储过程中使用ADO.NET和SQLCommand。我的问题是还有很多程序员的工作。我的意思是，与“获得更快的服务器”相比，开发人员花费了很多钱

3） 另一种方法是在SQL Server中定义表类型，并在ADO.NET中使用表值参数（请参阅）。这使您可以批量传递数据。您可以同时使用数据读取器和DataTable。请记住，数据读取器比数据表（二进制格式与XML表示形式）快得多

请记住，如果您偏离EF，您将承担额外的开发、QA和项目管理成本。EF提供了更快的开发时间，并减少了出错的机会，因为您不是在C#中硬编码表/列/存储过程名称。EF会自动同步，因此对数据库的任何更改都会在EF应用程序中显示为编译时错误。它们是使用ADO.NET时可怕的运行时错误

---

[编辑]请阅读上面的编辑。如果您有大量的消息，并且它们是一种记录类型（意味着以相同的方式写入相同的几个表），那么您可以使用ADO.NET进行优化，方法是在98%的代码中使用EF，并将大量JSON消息放入ADO.NET/存储过程或EF/存储过程。在较低级别上进行少量手动编码可能值得进行速度折衷。

“您是批量处理数据，还是考虑进行一组更改并一次性提交？我不认为我将对数据进行任何批量处理。”。这只是创建/检索帐户和消息。因此，可能最好在服务器收到请求时进行更新？@Hephaestious没有足够的上下文进行评论；什么服务器，什么请求，为什么需要更新？这是一个消息传递服务，例如a向B发送M。a的客户端将其发送到服务器，服务器将M添加到数据库中B的消息列表中。然后，B的客户机请求挂起的消息，服务器检查数据库，发送B的客户机M并从数据库中删除M。“编程更简单，出错几率更低”-不同的编程和不同的错误；两者都不是微不足道的，坦率地说，使用任何ORM或不使用ORM都很容易犯巨大错误；“我的问题是，还有很多程序员的工作”-像“dapper”这样的工具可以使这项工作基本上成为零，在通往第三方工具领域的黑暗道路上行走时要小心。代码的生命周期通常超过第三方工具的生命周期。在一个项目中，曾经有一次关于使用ReiserFS和ext3的争论（这是一个例子，或者依赖第三方不是问题的解决方案）。查找Hans Reiser——我们选择了ext3，但就长期支持而言，ReiserFS并不是最好的第三方选择。：-）这一点很好理解。对我来说，它不是第三方工具：）