linq-to-sql - 跨多个数据库构建数据层的最佳方法是什么？

Question

首先介绍一下环境:

我们使用名为 Clearview 的程序来管理与客户的服务关系，包括调用中心和现场服务工作。为了更好地支持客户和我们的现场技术人员，我们还开发了一个网站，提供对 Clearview 中的服务记录和报告的访问。随着时间的推移，我们对自定义行为和添加新功能的需求导致越来越多的东西与该网站及其数据库相关联。

此时，我们正在处理诸如部分在 Clearview 数据库中定义、部分在网站数据库中定义的公司之类的事情。为了更好地衡量，我们还开始将电话系统的脚本绑定(bind)到同一个网站，这也需要与电话系统自己的数据库进行通信。

所有这些都已设置完毕并正在运行...但是我们没有一个良好的数据层来处理这一切。我们迁移到 Linq to SQL，现在有两个可以使用的 DBML，以及我在听说 Linq 之前编写的一些自定义类，以及一些旧式 ADO 数据集。所以是的，基本上事情一团糟。

我想要的是一个数据层，它为我们的应用程序提供单个前端，并在后端将所有内容管理到正确的数据库中。

我听说过 Entity Framework 允许从多个源构建类，但事实证明只能有一个数据库。所以问题是，我该如何继续呢？

我目前正在考虑为每个数据库设置所有的 Linq To SQL 类，然后手动编写将这些类连接在一起的 Linq 兼容前端。看起来工作量很大，并且考虑到 Linq 的限制(例如无法刷新)，我不确定这是一个好主意。

我可以使用 Entity Framework 做一些效果更好的事情吗？我应该研究另一个工具吗？我疯了吗？

Answer 1

Entity Framework 确实提供了一定程度的数据库独立性，只要您可以从一个数据库构建实体模型，然后使用不同的实体连接字符串将其连接到不同的数据库。然而，正如你所说，它仍然只是一个数据库，而且，它仅限于支持 Entity Framework 的数据库。许多人这样做，但不是全部。您可以在单个应用程序中使用多个实体模型，以便使用 Entity Framework 组合多个数据库。 ADO.NET 团队博客上有一些相关信息。然而， Entity Framework 对此的支持充其量还处于早期阶段。

我解决这个问题的方法是将我对存储库模式背后的 Entity Framework 的使用进行抽象。对我来说，这样做最直接的好处是使单元测试变得非常简单；我没有尝试模拟我的实体模型，而是简单地替换返回 IQueryables 的模拟存储库。但相同的模式也非常适合组合多个数据源或没有 Entity Framework 提供程序的数据源，例如非数据服务感知的 Web 服务。

所以我不会说“不要使用 Entity Framework ”。我喜欢它，并且自己使用它。鉴于微软最近的消息，我相信它是比 LINQ to SQL 更好的选择。但它本身并不能解决您所描述的问题。使用存储库模式。