联接服务器和实体框架，有任何替代方案吗？

Question

3

我需要重写一个基于ASP.NET WebForms的日志查看器应用程序。新版本将基于ASP.NET MVC。

架构：

有一个Web前端，但是有多个分布在世界各地的数据库（按管辖区划分）。当前解决方案从中央DB到所有其他实例都有链接服务器。一些司法管辖区受到防火墙保护，但在防火墙上有一个例外规则，允许中央DB服务器连接到司法管辖区的SQL服务器。不允许其他连接。

他们在当前解决方案中所做的是，在中央服务器上创建一个单独的DB，其中包含通过链接服务器访问远程DB表的视图。如上所述，有一个UI实例。用户可以选择要检查日志的DB实例。

我想将其迁移到Entity Framework，如果使用相同的架构，它将起作用。

现在的问题是：是否有任何其他方法可以在不创建/维护这些链接数据库的情况下实现相同的结果？

- AcidJunkie

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Marcel N. · Accepted Answer

没有比EF 6.1更简单的了。

如果EF支持同义词，那么您可以在中央数据库中为所有链接数据库中的表（当然是在不同模式下）创建同义词。这将减轻一些开销，因为同义词比视图更容易维护，并且您可以使用DataTools项目轻松完成中央数据库的操作。

目前，同义词支持是EF下一个版本的建议。

至于现在，为什么不在中央数据库中创建和维护视图？每个链接服务器/数据库一个模式：

[jurisdiction1].[vTableA]
[jurisdiction1].[vTableB]
...
[jurisdictionN].[vTableA]

类似于同义词，但缺点是需要编写更多的视图代码。您仍然可以使用DataTools进行版本控制、更改跟踪和提供增量更新脚本。

如果您认为现在管理数据库很困难，我建议您了解一下DataTools。它们使模式管理变得更加容易处理。