跨多个数据库构建数据层的最佳方法是什么？
首先介绍一下环境：
我们使用名为 Clearview 的程序来管理与客户的服务关系，包括呼叫中心和现场服务工作。 为了更好地支持客户和我们的现场技术人员，我们还开发了一个网站，提供对 Clearview 中的服务记录和报告的访问。 随着时间的推移，我们对自定义行为和添加新功能的需求导致越来越多的东西与该网站及其数据库相关联。
此时，我们正在处理诸如部分在 Clearview 数据库中定义、部分在网站数据库中定义的公司之类的事情。 为了更好地衡量，我们还开始将电话系统的脚本绑定到同一个网站，这也需要与电话系统自己的数据库进行通信。
所有这些都已设置并正在运行......但是我们没有一个良好数据层来处理这一切。 我们迁移到 Linq to SQL，现在有两个可以使用的 DBML，以及我在听说 Linq 之前编写的一些自定义类，以及一些旧式 ADO 数据集。 所以是的，基本上事情一团糟。
我想要的是一个数据层，它为我们的应用程序提供单个前端，并在后端将所有内容管理到正确的数据库中。
我听说过实体框架允许从多个源构建类，但事实证明只能有一个数据库。 所以问题是，我该如何继续呢？
我目前正在考虑为每个数据库设置所有 Linq To SQL 类，然后手动编写 Linq 兼容前端将它们连接在一起。 看起来工作量很大，并且考虑到 Linq 的限制（例如无法刷新），我不确定这是一个好主意。
我可以使用实体框架做一些效果更好的事情吗？ 我应该研究另一个工具吗？ 我疯了吗？
First a bit about the environment:
We use a program called Clearview to manage service relationships with our customers, including call center and field service work. In order to better support clients and our field technicians we also developed a web site to provide access to the service records in Clearview and reporting. Over time our need to customize the behavior and add new features led to more and more things being tied to this website and it's database.
At this point we're dealing with things like a Company being defined partly in the Clearview database and partly in the website database. For good measure we're also starting to tie the scripting for our phone system into the same website, which will require talking to the phone system's own database as well.
All of this is set up and working... BUT we don't have a good data layer to work with it all. We moved to Linq to SQL and now have two DBMLs that we can use, along with some custom classes I wrote before I'd ever heard of Linq, along with some of the old style ADO datasets. So yeah, basically things are a mess.
What I want is a data layer that provides a single front end for our applications, and on the back end manages everything into the correct database.
I had heard something about Entity Framework allowing classes to be built from multiple sources, but it turns out there can only be one database. So the question is, how could I proceed with this?
I'm currently thinking of getting the Linq To SQL classes all set for each database, then manually writing Linq compatible front ends that tie those together. Seems like a lot of work, and given Linq's limitations (such as not being able to refresh) I'm not sure it's a good idea.
Could I do something with Entity Framework that would turn out better? Should I look into another tool? Am I crazy?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
实体框架确实提供了一定程度的数据库独立性，只要您可以从一个数据库构建实体模型，然后使用不同的实体连接字符串将其连接到不同的数据库。 然而，正如你所说，它仍然只是一个数据库，而且，它仅限于支持实体框架的数据库。 许多人这样做，但不是全部。 您可以在单个应用程序中使用多个实体模型，以便使用实体框架组合多个数据库。 ADO.NET 团队博客上有一些相关信息。 然而，实体框架对此的支持充其量还处于早期阶段。
我解决这个问题的方法是抽象我对存储库模式背后的实体框架的使用。 对我来说，这样做最直接的好处是使单元测试变得非常简单； 我没有尝试模拟我的实体模型，而是简单地替换返回 IQueryables 的模拟存储库。 但同一模式也非常适合组合多个数据源或没有实体框架提供程序的数据源，例如非数据服务感知的 Web 服务。
所以我不会说“不要使用实体框架”。 我喜欢它，并且自己使用它。 鉴于微软最近的消息，我相信它是比 LINQ to SQL 更好的选择。 但它本身并不能解决您所描述的问题。 使用存储库模式。
The Entity Framework does give a certain measure of database independence, insofar as you can build an entity model from one database, and then connect it to a different database by using a different entity connect string. However, as you say, it's still just one database, and, moreover, it's limited to databases which support the Entity Framework. Many do, but not all of them. You could use multiple entity models within a single application in order to combine multiple databases using the Entity Framework. There is some information on this on the ADO.NET team blog. However, the Entity Framework support for doing this is, at best, in an early stage.
My approach to this problem is to abstract my use of the Entity Framework behind the Repository pattern. The most immediate benefit of this, for me, is to make unit testing very simple; instead of trying to mock my Entity model, I simply substitute a mock repository which returns IQueryables. But the same pattern is also really good for combining multiple data sources, or data sources for which there is no Entity Framework provider, such as a non-data-services-aware Web service.
So I'm not going to say, "Don't use the Entity Framework." I like it, and use it, myself. In view of recent news from Microsoft, I believe it is a better choice than LINQ to SQL. But it will not, by itself, solve the problem you describe. Use the Repository pattern.
如果您想使用 Linq2SQl 或 EF 等工具，并且不想管理多个 DBMLS（或在 EF 或其他工具中调用的任何名称），您可以在网站数据库中创建视图，该视图引用回 ClearView 或 Phone系统的数据库。
这允许您将网站与其数据库结构分离。 我相信 Linq2Sql 和 EF 可以使用视图作为实体的源。 如果他们不能看nHibernate。
这还可以让您拥有从各种数据源提取的复合实体。 SQL Server 中更新视图存在一些限制； 但是，您可以在视图上定义自己的而不是触发器，然后它可以执行实际的插入更新删除语句。
if you want to use tools like Linq2SQl or EF and don't want to have to manage multiple DBMLS (or whaetever its called in EF or other tools), you could create views in your website database, that reference back to the ClearView or Phone system's DB.
This allows you to decouple your web site from their database structure. I believe Linq2Sql and EF can use a view as the source for an Entity. If they can't look at nHibernate.
This will also let you have composite entities that are pulled from the various data sources. There are some limitations updating views in SQL Server; however, you can define your own Instead of trigger(s) on the view which can then do the actual insert update delete statements.
在我的项目中，L2S 与视图完美配合。 你只需要做一个小技巧：
1. 将辅助数据库表作为视图添加到当前数据库中。
2. 在 Designer 中，将主键属性添加到视图上的 id 字段。
3. 现在，将关联添加到原始数据库中您想要的任何其他表。
现在，您可能会看到可用于导航的视图。
L2S works with views, perfectly, in my project. You only need to make a small trick:
1. Add a secondary DB table to the current DB as a view.
2. In Designer, add a primary key attribute to a id field on the view.
3. Only now, add an association to whatever other table you want in the original DB.
Now, you might see the view available for the navigation.