从 ADO 迁移到 ADO.net答案

【问题标题】：Moving from ADO to ADO.net从 ADO 迁移到 ADO.net
【发布时间】：2013-02-25 07:40:18
【问题描述】：

我正在重新设计一个使用 ADO 通信连接到 SQL 的产品。业务层使用 c++。整个查询都写为 SP。我希望产品支持 SQL 2008 并且可能是 Mysql（尚未最终确定）。

这些是我想到的变化！

我想要对此的反馈/建议。这是一个很好的过渡吗？

【问题讨论】：

首先，我们在谈论什么样的规模——这是 20 吗？ 200？ SP？另外：如果您现有的 SP 工作正常，为什么不通过 ADO.NET 过渡到 SP？此处无需跳转到 ad-hoc SQL。不过，我要说的主要内容是：避免DataTable 等的诱惑；没有什么好处:)
目前的产品使用SQL 2005。我想把它移到SQL 2008 可能在下一个版本想支持MySQL。我也在考虑类似的路线。但是，C++ 中用于业务层的 ado.net 的 C# 包装器会导致任何性能障碍吗？

【解决方案1】：

根据个人喜好，我会创建 LINQ2SQL 或可能的实体框架层来访问数据库。 LINQ2SQL 和实体框架都可以导入和调用存储过程的定义¹。

然后我会逐渐将存储过程转换为 LINQ 代码。

¹) 在合理的范围内，具有多个返回集和选择不是来自单个表的 SP:s 必须手动映射，但它仍然是可能的。

【讨论】：

我有一个问题。 Linq2SQL 支持 MySQL 吗？ .听说实体不错。但这对我来说将是很多工作。我认为从 ado 迁移到 ado.net 会带来更好的性能。不是吗？
我认为 Linq2SQL 有第三方 MySQL 提供程序，但我会选择 EF。原始 ADO.NET 比使用 OR 映射器快一点，但另一方面，使用 OR 映射器编写代码通常比直接使用 ADO.NET 更快且不易出错。
创建一个小型测试项目，将您的数据库作为 EF 模型导入，您将立即看到您的 SP:s 是否与 EF 设计器兼容。
感谢您的回复..我想我会在第 2 阶段做这件事，EF 听起来不错.. 在第 1 阶段我正在考虑将通信转移到 ADO.net 并用 C# 编写一个包装器和在 C++ 中的业务层中使用。存储过程将保持不变，它将由 C# 代码调用。如果我在第 1 阶段这样做（我知道 C++ 将使用 com 互操作性调用 C#）会导致任何性能障碍吗？你的意见是什么。
哦好吧..我会写一个测试项目！！但是，如果我有一个 SP 进行备份/存档（通常是 SP 处理大量数据）的东西，最好把它排除在 EF 之外？