sql-server - 从 LINQ to SQL 迁移到 DocumentDB 的好方法是什么？

Question

首先，介绍一下我们情况的一些背景。几年前，我开始使用 LINQ to SQL 作为 DAL 的 ASP.NET MVC 项目。作为当时该项目的唯一开发人员，我选择使用它是因为它在社区中得到了很好的支持，并且我需要更多地关注应用程序逻辑和 UI 设计，以便我可以将其推向市场。这个策略对我们来说非常有效。

不过，没过多久，我就需要在 Windows 服务中针对同一数据存储编写一些多线程代码。 LINQ to SQL 遇到了各种跨线程的问题。作为当时唯一的开发人员，并且需要快速启动此服务，我采取了使用 POCO 和企业库复制足够的 DAL 和模型的方法。虽然不是具有重复模型和 DAL 功能的理想架构，但它运行良好并帮助我完成了任务。

那是五年前的事了。我们的项目已经取得了成功，但现在这种成功不再是 LINQ 或 Enterprise Library 的责任，而是 SQL 本身的责任。现在，在有人建议我们对 SQL 数据库进行索引和所有其他操作之前，我们已经这样做了。我们增加了一名契约(Contract) DBA，他为我们解决了问题。性能已恢复，一切正常。但问题是(在我们看来)它需要对我们的业务模型和需求进行过于频繁的维护。

值得庆幸的是，微软已经通过 Azure 服务加强了他们的游戏。我们特别感兴趣的是 DocumentDB(我们现在有两名开发人员)。在 SQL 中，我们有几个大型、扁平、繁忙的表，当我们开始满足数据库维护需求时，这些表会给应用程序的某些区域带来严重的性能问题。我们根本没有资源用于持续维护。我们决定将应用程序部分或全部迁移到 DocumentDB。一些概念验证演示内部告诉我们，这对于我们拥有的应用程序类型来说是一个很好的举措。

如果您已经读到这里，谢谢您，这是我的问题。将 LINQ to SQL 类和生成的逻辑迁移到 DocumentDB 支持的 DAL 的好方法是什么？值得庆幸的是，我很早就有先见之明，使用 IRepository 方法，这样应用程序本身就不会受到影响，希望根本不会受到影响。我最关心的是 LINQ to SQL 设计界面为我编码的所有“神奇”CRUD 内容。我和我的其他开发人员当然了解如何编写我们自己的 DAL 代码，但我们需要一种快速且一致的方法，该方法考虑到应用程序编码所期望的由 LINQ to SQL 支持的行为。

我的本​​能是基本上展开 LINQ to SQL 五年前为我生成的所有生成代码，并将其与 LINQ to SQL 设计器分离，通过 DI 添加我们自己的 DAL，然后从那里开始。我的另一个开发人员在这方面比我更先进，所以我对我们能够完成它有相当大的信心。只是希望有人可以帮助我们避免陷阱，以便我们能够有效地完成这项工作。

Answer 1

正如 David Makogon 在评论中指出的那样，这个问题确实没有“正确”答案，因为它非常广泛且基于观点。我收到了各种各样的建议，但我认为没有一个是明确的答案。