2

假设我有一个数据库，这个数据库有一组对所有客户端通用的表和一些特定于某些客户端的表。

现在我想到的是创建一个DataContext只包含对所有客户端通用的表的主数据库，然后创建单独DataContext的只包含特定于客户端的表的 s。

有没有办法让“合并”DataContext成为一个上下文？ 因此，对于客户端 A，我需要一个 DataContext，它既包括通用表，也包括该特定客户端的表（从两个不同DataContext的 s 中检索）？

[更新]

我想我能做的是，从 DataContext 的 Partial 类，而不是让我的 DataContext 继承自，DataContext我让它继承自MyDataContext；这样，来自MyDataContext和其他 DataContext 的表将在一个DataContext类中可用。

您如何看待这种方法？当然，这样的事情你只能一次合并两个数据上下文......

4

4 回答 4

2

我会使用外观模式。创建一个外观上下文，它将从用户那里抽象出底层的 DataContext。如果需要，您可以从 Default DataContext 继承并覆盖这些方法。在覆盖范围内，您可以将其传递给适当的 DataContext。

于 2009-06-11T14:08:34.743 回答
1

无论如何，我不知道以编程方式实现这一目标。

您可能想要查看的是使用设计模式来实现这一目标。通过使用模式以及存储库模式，您可以定义所有客户端存储库都将从中继承的基本接口存储库。然后，对于每个客户端存储库，您可以根据他们的特定需求对其进行扩展。

于 2009-06-11T14:01:24.887 回答
0

我们通过在 DataContexts 中使用继承来实现这一点，我们将 EF5、Code-First 和 MVC4 用于前端 Web 项目。

我们有一个通用的DataContext来封装我们数据库中所有的通用表

public partial class CommonDataContext : DbContext
{
    //Your code
}

以及使用自己的表 + 公用表的多个专用数据上下文

public partial class Application1Context : CommonDataContext
{
    //Your code
}

这些数据上下文中的每一个都位于同一解决方案中的不同项目中。希望这有帮助。

于 2013-04-05T16:30:42.613 回答
0

我不知道你是否已经想通了，但是合并 DataContexts 并不是一个好主意。很大一部分原因与 DataContext 对象中内置的更改跟踪有关。如果您能够将实体对象保持分离，以便更改一次只影响一个 DataContext 而没有重叠，那么您可以让它工作，但是对于这么少的回报来说似乎太麻烦了。

您可以实现存储库模式，但同样，您仍然会遇到一个 DataContext 无法识别使用另一个 DataContext 创建的对象的问题。我目前工作的项目只使用一个 DataContext。数据库现在有大约 75 个表...我有一对一、一对多和多对多关系，我还没有遇到严重的性能或实现问题，只使用一个 DataContext . 使用外观模式可能有效，但同样，您需要问自己，维护多个不能直接交互的 DataContext 是否值得付出努力。

例如，假设您有一个 Customer 表和 Orders 表。Customer 表位于一个 DataContext 中，而 Orders 表位于另一个 DataContext 中。这种关系是一个客户对零到多个订单。因为您将它们放在单独的 DataContexts 中，所以我不相信您可以在查询中直接引用子实体对象。因此，要获得特定客户的订单，您可能会被迫这样做：

var orders = DC2.Orders.Where(a => a.Customer_ID == (DC1.Customers.Where(a => a.Customer_ID == 7).Customer_ID);

而不是这个：

var orders = DC.Customers.Where(a => a.Customer_ID == 7).Select(a => a.Orders);
于 2010-03-27T05:35:42.477 回答