【发布时间】：2015-07-26 06:20:51
【问题描述】：
首先，介绍一下我们的情况。几年前，我开始了一个使用 LINQ to SQL 作为 DAL 的 ASP.NET MVC 项目。作为当时该项目的唯一开发人员，我选择使用它是因为它在社区中得到了很好的支持，我需要更多地关注应用程序逻辑和 UI 设计，以便将其推向市场。这种策略对我们来说效果很好。
不过，没过多久，我就需要在 Windows 服务中针对同一数据存储编写一些多线程代码。 LINQ to SQL 遇到了各种跨线程问题。当时我仍然是唯一的开发人员，并且需要快速启动这项服务，因此我使用 POCO 和企业库复制了足够多的 DAL 和模型。虽然不是具有重复模型和 DAL 功能的理想架构，但它运行良好并且让我通过了。
那是五年前的事了。我们的项目已经取得了成功，现在这种成功不是 LINQ 或企业库的责任，而是 SQL 本身的责任。现在，在任何人建议我们用索引和所有这些对我们的 SQL 数据库进行大修之前，我们已经做到了。我们在合同上增加了一个 DBA，他为我们解决了问题。性能已恢复，一切正常。但问题在于（在我们看来）需要对我们的业务模型和需求进行过于频繁的维护。
值得庆幸的是，Microsoft 已通过 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 并从那里开始。我的另一个开发人员在这方面比我更先进，所以我有相当大的信心相信我们可以完成它。只是希望有人可以帮助我们避免陷阱，以便我们能够有效地完成这项工作。
【问题讨论】：
-
我还应该补充一点，我担心如何维护 LINQ to SQL 在实体之间保持的关系。我真正喜欢 LINQ to SQL 的一件事是，您可以依靠父子关系在数据上下文中进行跟踪。在应用程序中，您可以轻松添加、删除或更改子实体，调用单个更新方法，所有这些关系都得到尊重，无需任何大惊小怪和最少的代码。理想情况下，这是我们希望在 DocumentDB DAL 中保留的行为。
-
如果您一直在使用 RDBMS 和 ORM 功能，您会发现迁移接近于重写。 DocumentDB 没有为您提供一种以有效方式替换许多 RDBMS 查询的方法。例如，您不能将连接推送到数据库（DocDB 只有同文档连接 AFAIK）。因此，您现有的 IRepository 抽象不会对您有太大帮助。此外，我会质疑切换到 DocDB 的必要性，因为您从中获得的功能和性能更少。相反，简化您对数据库的使用并解决问题。
-
通常，人们切换到 NoSQL 并声称性能有所提高。但真正提高性能的是 RDBMS 也提供了一个更简单的数据模型。
-
是的，我也考虑过这种效果，我相信它会在某种程度上得到证明。但是，我们的合同 DBA 在数据库级别监控主要问题区域的 SQL，发现应用程序明显存在故障的 5 个区域中只有 1 个。一旦他优化并重建了索引，应用程序就会像第一天一样飞起来。
-
就接近重写而言，我认为您的评论是正确的。这就是我感觉到的，这就是为什么我想在我们深入研究之前把它扔在那里进行审查。
标签： sql-server azure linq-to-sql database-migration azure-cosmosdb