Stored procedures 从数据集到存储过程和现代ORM的转换

要将现有的大型代码库从强类型数据集驱动的数据访问层迁移到由存储过程和/或更现代的ORM包驱动的DAL，需要付出多少努力？是否有任何闪亮的工具可以自动化这一过程的一部分

当前的代码库有超过100个镜像sql数据库的数据集（但并不总是与数据库结构中的更改100%同步）。目前的立场是，现在要改变需要花费太多的时间/精力，但我怀疑这会让我们每周还清多少技术债务。这更不用说数据集SQL后端的性能与优化存储过程的性能了

---

那么，这是合理的吗？这样的事情是不是太可怕了，不可能在合理的时间内解决并获得有价值的回报？我知道我可以将它们使用的DAO类更改为接口（应该已经），并在生产中使用数据集的同时进行开发，直到可以对整个系统的一小部分进行某种可行性测试为止

我想说，与存储过程驱动的DAL层相比，转向像LINQ到SQL这样的ORM将大大减少工作量。我脑海中浮现的几件事：

• 情况1-如果您在DAL之外使用类型化数据集[in UI，BLL]，那么工作量肯定会很大，因为您需要对更改进行广泛的影响分析，并在几乎所有使用类型化数据集的地方进行更改

• 情况2-如果您只在DAL和UI中使用类型化数据集，BLL不关心DAL的内部实现，也不关心类型化数据集，那么这将大大减少工作量。您只需要在DAL层内进行更改

• 如果您处于情况2，那么我认为从类型化数据集转移到ORM映射器肯定是值得的

• 如果您打算采用DAL的存储过程方法，那么您可以访问www.mygenerationsoftware.com来自动生成过程，以减少一些工作量，但是与ORM映射器相比，工作量仍然会更大，另一个缺点可能是您的数据库中会有无数个简单的插入/更新过程。我们通常主要将PROC用于级联递增（update+insert）或复杂计算，并将LINQ to SQL用于基本插入、更新和删除

---

希望这对你有所帮助

我同意，我们不需要为每一个CRUD操作都使用一个存储过程，只需要为比这更复杂的事情使用存储过程。我必须阅读一些代码（我几周前刚开始在这个公司工作），看看会有什么影响。乍一看，似乎每个数据集都在一个“DataManager”类的后面，这个类95%通过数据集，所以我认为它没有从DAL中泄漏出来。听起来最难的部分是让鞋面相信时间是值得的。。。