对于一个大型项目，有一个datacontext映射出你的数据库是否有意义，你可以从你的类中进行交互？
或者将它分成小型数据文件更有意义，这些数据文本专注于数据库中将需要的特定任务。
我对表现感到好奇。我的理解是datacontext本身是一个非常轻量级的对象，它只在需要时初始化它的内部集合等。在处理具有许多定义但只有两个数据表的datacontext时应该和处理特殊的datacontext一样快只有那两张桌子。
我也认为你会在JIT时间受益，因为第一个进行数据访问的类将编译你的dc，现在所有类都可以使用。
答案 0 :(得分：9)
我假设你在询问设计与运行时模式。我一般说我会说没有：
虽然可以将数据库划分为多个数据上下文，但是当且仅当两个上下文之间没有重叠时才是可取的。
重叠错误
e.g。您有WebsiteContext和AdminContext。 WebsiteContext用于显示Product并履行Order。 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模式一样。在这种情况下，您仍然可以使用逻辑层来处理细节。
虽然您可能不希望上下文的责任如此广泛，但数据上下文只是数据库的表示。它不是一种安全机制，它无法阻止您破坏数据。
答案 1 :(得分：1)
从“存储库模式”的角度来看，有一些内容可以说是具有单独的聚合并最小化聚合之间的导航属性。我不是100％确定是的东西......目前我正在考虑使用中等大小的dbml，多个存储库使用它（ UI不直接使用datacontexts - 只有存储库类，导航属性标记为内部，因此DAL可以使用它们......也许......