我应该使用一个LINQ DataContext还是多个？

对于一个大型项目,有一个datacontext映射出你的数据库是否有意义,你可以从你的类中进行交互？

或者将它分成小型数据文件更有意义,这些数据文本集中在数据库中将需要的特定任务上.

我对表现感到好奇.我的理解是datacontext本身是一个非常轻量级的对象,它只在需要时初始化它的内部集合等.在处理具有许多定义但只有两个数据表的datacontext时应该和处理特殊的datacontext一样快只有那两个表.

我也认为你会在JIT时间受益,因为第一个进行数据访问的类将编译你的dc,现在所有类都可以使用它.

我假设你在询问设计与运行时模式.我一般我会说没有:

虽然可以将数据库划分为多个数据上下文,但是当且仅当两个上下文之间没有重叠时,这才是可取的.

重叠是坏的

例如,你有一个WebsiteContext和一个AdminContext.该WebsiteContext用于显示Product和履行Order秒.A WebsiteUser附在一个Order.这AdminContext是为您的Staff会员处理已取消的退款Orders,也是参考WebsiteUser.该AdminContext还需要重置密码,并更新了其他细节WebsiteUser.

您正在考虑这样做,因为您不希望网站处理或甚至不知道 Returns

WebsiteContext
Product -- Order -- WebsiteUser

AdminContext
Staff -- Returns -- Order -- WebsiteUser 

在上面,我们可以看到我们在不同的数据上下文中复制了很多对象.这闻起来很糟糕,它确实表明人为地将数据库划分到不同的数据上下文是一个错误的决定.毕竟你有> 2个数据库,还是只有一个？复制违反了DRY原则(不要重复自己),因为WebsiteContext.WebsiteUser与AdminContext.WebsiteUser不同,并且当某些东西需要关心他们引用哪一个时,代码很可能会变得混乱.

Linq数据上下文只是一个OR映射器,需要被视为一个花哨的黑盒子,这使得编写一些数据访问代码更容易.一些linq演示使您看起来不再需要其他层,但任何复杂程序仍然可以从分层设计中受益.

您可能最好将Linq对象视为仅用于轻松传输数据的对象,并创建一个将其隐藏为实现细节的Domain层.阅读DDD - 域驱动设计.

就其本身而言,仅使用UI中的Linq对象最类似于Transaction Script模式.在这种情况下,您仍然可以使用逻辑层来处理细节.

虽然您可能不希望上下文的责任如此广泛,但数据上下文只是数据库的表示.它不是一种安全机制,它无法阻止您破坏数据.