首先，我们的情况有一点背景。几年前，我使用LINQ to SQL作为DAL启动了一个ASP.NET MVC项目。作为当时唯一的项目开发人员，我选择使用它，因为它在社区中得到了很好的支持，我需要更多地关注应用程序逻辑和UI设计，以便我可以将它推向市场。这个策略对我们来说非常好。
但是，在我需要在同一数据存储的Windows服务中编写一些多线程代码之前，它还不长。 LINQ to SQL遇到了跨线程的各种问题。仍然是当时唯一的开发人员，需要快速获得这项服务，我使用POCO和企业库来复制DAL和模型。虽然不是理想的具有重复模型和DAL功能的架构，但它运行良好并让我度过难关。 那是五年前的事了。我们的项目已经取得了成功，现在非常成功的问题不是LINQ或Enterprise Library，而是SQL本身。现在，在任何人建议我们为SQL数据库提供索引和所有这些的全面改造之前，我们已经做到了这一点。我们在合同上添加了DBA，他为我们解决了问题。性能恢复，一切都很好。但问题是，（我们认为）需要对我们的业务模式和要求进行过于频繁的维护。值得庆幸的是，微软已经加强了与Azure服务的竞争。我们（我们现在有两个开发人员）特别感兴趣的是DocumentDB。在SQL中，我们有几个大而平坦的繁忙表，当我们开始接近数据库维护需求时，这些表给我们的应用程序的某些方面带来严重的性能问题。我们根本没有资源投入持续维护。我们决定将我们的应用程序部分或全部移至DocumentDB。一些概念证明演示在内部告诉我们，对于我们的应用类型来说，这是一个很好的举措。
如果你已经读过这篇文章了，谢谢你，这是我的问题。将LINQ迁移到SQL类并将生成的逻辑迁移到由DocumentDB支持的DAL的好方法是什么？值得庆幸的是，我很早就开始使用IRepository方法，这样应用程序本身就不会受到影响。我主要关心的是所有的＆＃34;魔法＆＃34; LINQ to SQL设计表面编码的CRUD东西。我的其他开发人员和我当然理解如何编写自己的DAL代码，但我们需要一种快速一致的方法，该方法考虑了应用程序编码的行为，期望得到LINQ to SQL的支持。
我的本能是基本解开LINQ to SQL五年前为我做的所有生成的代码，并将它与LINQ to SQL设计器分开，通过DI添加我们自己的DAL并从那里开始。我的其他开发人员比我在这方面做得更先进，所以我有相当大的信心，我们可以完成它。只是希望有人可以帮助我们避免陷阱，这样我们就可以有效地完成这项任务。
答案 0 :(得分：0)
正如David Makogon在评论中指出的那样，这个问题确实没有“正确的”＃34;答案因为它非常广泛和基于意见。我得到了广泛的建议，但我没有想到任何明确的答案。