将大型现有代码库从强类型数据集驱动的数据访问层迁移到由存储过程和/或更现代的ORM包驱动的DAL需要花费多少精力？是否有任何闪亮的工具可以自动完成此过程的一部分？
当前代码库有超过100多个镜像sql数据库的数据集（但并不总是100％与DB结构中的更改同步）。目前的立场是，现在改变的时间/努力太多，但我怀疑这使我们每周付出多少技术债务。这就是说数据集的SQL与优化的sproc后端的性能无关。
那么，这是否合理？这样的事情会在合理的时间内解决太多的怪物并获得有价值的回报吗？我知道我可以改变它们用于接口的DAO类（应该已经是）并在开发时使用生产中的数据集，直到可以在整个的一小部分上进行某种可行性测试。
答案 0 :(得分：2)
我想说，与存储的proc驱动的DAL层相比，继续使用像LINQ to SQL这样的ORM将会更加省力。我想到的一些事情很少：
情况1 - 如果您在DAL [在UI，BLL]之外使用您的类型化数据集，那么您的努力肯定会很高，因为您需要对更改进行广泛的影响分析并制作几乎在您使用类型化数据集的地方都会发生变化。
情况2 - 如果您只使用DAL和UI的类型化数据集，BLL不关心DAL的内部实现并且忘记了类型化的数据集，那么它将大大减少工作量。您只需要在DAL层内进行更改。
如果您处于情境2中，那么我认为从类型化数据集转移到ORM映射器肯定是值得的。
如果您打算采用DAL的存储过程方法，那么您可以查看www.mygenerationsoftware.com以自动生成您的过程以减少一些努力，但是与ORM映射器相比，努力仍然会更高另一个缺点可能是你在数据库中最终只有简单的插入/更新过程。我们通常主要使用procs进行级联UPSERTS（更新+插入）或复杂计算，并使用LINQ to SQL进行基本插入，更新，删除。
希望这在某种程度上有所帮助！