假设我有一个数据库,并且此数据库有一组通用于所有客户端的表和一些特定于某些客户端的表。
现在我要记住的是创建一个主DataContext
,它只包含所有客户端通用的表,然后创建单独的DataContext
,它们只包含特定于客户。
有没有办法可以“合并”DataContext
以便它成为一个上下文?所以对于客户端A,我需要一个包含通用表格的DataContext该特定客户端的表(从两个不同的DataContext
中检索)?
[更新]
我认为我可以做的是,从DataContext的Partial Class而不是让我的DataContext继承自DataContext
,我让它继承自MyDataContext
;这样,来自MyDataContext
的表和另一个DataContext将在一个DataContext
类中可用。
您如何看待这种方法?当然,有了类似的东西,你只能同时合并两个datacontexts ......
答案 0 :(得分:2)
我会使用Facade Pattern。创建一个Facade上下文,它将从用户中抽象出底层的DataContext。如果需要并可以重写方法,则可以从Default DataContext继承。在覆盖内,您可以将其传递给相应的DataContext。
答案 1 :(得分:1)
我不知道无论如何要实现这个目标。
您可能希望看到的是使用设计模式来实现此目标。通过使用模式以及存储库模式,您可以定义所有客户端存储库将继承的基本接口存储库。然后,对于每个客户端存储库,您可以根据其特定需求进行扩展。
答案 2 :(得分:0)
我不知道你是否已经想到这一点,但合并DataContexts并不是一个好主意。其中很大一部分原因与DataContext对象中内置的更改跟踪有关。如果你能够将实体对象分开,以便更改一次只影响一个DataContext而没有重叠,那么你可以让它工作,但这对于这么少的收益来说似乎很麻烦。
您可以实现存储库模式,但同样,您仍然遇到一个DataContext无法识别使用其他DataContext创建的对象的问题。我目前正在使用的项目只使用一个DataContext。数据库现在有大约75个表...我有一对一,一对一,多对多的关系,我还没有使用一个DataContext遇到严重的性能或实现问题。使用外观模式可能会起作用,但同样,您需要问自己,维护多个无法直接交互的DataContex是否值得付出努力。
例如,假设您有一个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);
答案 3 :(得分:0)
我们通过在DataContexts中使用继承来实现这一点,我们使用EF5,Code-First和MVC4进行前端Web项目。
我们有一个通用的DataContext来封装数据库中的所有公共表
public partial class CommonDataContext : DbContext
{
//Your code
}
使用自己的表+公共表的多个专用数据上下文
public partial class Application1Context : CommonDataContext
{
//Your code
}
这些数据上下文中的每一个都位于同一解决方案中的单独项目中。 希望这有帮助。