或者将它分成小型数据文件更有意义,这些数据文本集中在数据库中将需要的特定任务上.
我对表现感到好奇.我的理解是datacontext本身是一个非常轻量级的对象,它只在需要时初始化它的内部集合等.在处理具有许多定义但只有两个数据表的datacontext时应该和处理特殊的datacontext一样快只有那两个表.
我也认为你会在JIT时间受益,因为第一个进行数据访问的类将编译你的dc,现在所有类都可以使用它.
解决方法
虽然可以将数据库划分为多个数据上下文,但是当且仅当两个上下文之间没有重叠时,这才是可取的.
重叠是坏的
例如你有一个WebsiteContext和一个AdminContext. WebsiteContext用于显示产品和履行订单. WebsiteUser附加到订单. AdminContext供您的员工处理已取消订单的退款,该订单也会引用WebsiteUser. AdminContext还需要重置密码并更新WebsiteUser的其他详细信息.
您正在考虑这样做,因为您不希望网站处理甚至知道退货
WebsiteContext Product -- Order -- WebsiteUser AdminContext Staff -- Returns -- Order -- WebsiteUser
在上面,我们可以看到我们在不同的数据上下文中复制了很多对象.这闻起来很糟糕,它确实表明人为地将数据库划分到不同的数据上下文是一个错误的决定.毕竟你有> 2个数据库,还是只有一个？复制违反了DRY原则(不要重复自己),因为WebsiteContext.WebsiteUser与AdminContext.WebsiteUser不同,并且当某些东西需要关心他们引用哪一个时,代码很可能会变得混乱.
Linq数据上下文只是一个OR映射器,需要被视为一个花哨的黑盒子,这使得编写一些数据访问代码更容易.一些linq演示使您看起来不再需要其他层,但任何复杂程序仍然可以从分层设计中受益.
您可能最好将Linq对象视为仅用于轻松传输数据的对象,并创建一个将其隐藏为实现细节的Domain层.阅读DDD – 域驱动设计.
就其本身而言,只使用UI中的Linq对象最类似于事务脚本模式.在这种情况下,您仍然可以使用逻辑层来处理细节.
虽然您可能不希望上下文的责任如此广泛,但数据上下文只是数据库的表示.它不是一种安全机制,它无法阻止您破坏数据.
