对于一个大型项目，使用一个数据上下文来映射您的数据库是否有意义，您可以从您的类中与之交互？
或者将其拆分为小型数据上下文更有意义，这些数据上下文专注于数据库中所需的特定任务。
我很好奇性能。据我了解，数据上下文本身是一个非常轻量级的对象，它只在需要时初始化其内部集合等。因此处理具有许多定义但只有两个数据表的数据上下文应该与处理特殊数据上下文一样快只有那两个表。
我还认为您会在 JIT 时间受益，因为第一个进行数据访问的类将编译您的 dc，它现在可用于所有类。
最佳答案
我假设您问的是设计与运行时模式。我一般会说不:
虽然可以将您的数据库划分为多个数据上下文，但当且仅当两个上下文之间的重叠为零时，这才是可取的。
重叠不好
例如你有一个 WebsiteContext 和一个 AdminContext。 WebsiteContext 用于显示Product 和完成Order。 WebsiteUser 附加到 Order。 AdminContext 供您的 Staff 成员处理已取消的 Orders 的退款，它还引用了 WebsiteUser。 AdminContext 还需要重置密码并更新 WebsiteUser 的其他详细信息。
您考虑这样做是因为您不希望网站处理甚至不知道返回
WebsiteContext
Product -- Order -- WebsiteUser
AdminContext
Staff -- Returns -- Order -- WebsiteUser
在上面，我们可以看到我们在不同的数据上下文中复制了许多对象。这闻起来很糟糕，它确实表明人为地将数据库划分为不同的数据上下文是一个错误的决定。毕竟你有> 2个数据库，还是只有一个？重复违反了 DRY 原则(不要重复自己)，因为 WebsiteContext.WebsiteUser 与 AdminContext.WebsiteUser 不同，并且当某些东西需要关心它们引用的是哪一个时，代码很可能会变得困惑。
Linq 数据上下文只是一个 OR 映射器，需要将其视为一个奇特的黑盒，以便更轻松地编写一些数据访问代码。一些 linq 演示让您看起来不再需要其他层，但任何复杂的程序仍然受益于分层设计。
您可能最好将 Linq 对象仅视为用于轻松传输数据的对象，并创建一个将它们隐藏为实现细节的域层。阅读 DDD - 领域驱动设计。
就其本身而言，仅使用 UI 中的 Linq 对象最类似于 Transaction Script 模式。在这种情况下，您仍然可以从处理细节的逻辑层中获益。
虽然您可能不希望上下文的职责如此广泛，但数据上下文只是数据库的一种表示。它不是一种安全机制，也不能防止您破坏数据。
关于c# - 我应该使用一个 LINQ DataContext 还是多个？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/559441/