【发布时间】：2009-03-27 05:31:00
【问题描述】：
最好是拥有一个包含所有表的胖数据上下文类，还是将它们分成更小的类并可能具有“单表”类？
从组织的角度来看，我觉得我不应该在多个数据上下文中拆分关系（我什至认为这是不可行的）。但另一方面，我认为创建该胖类的全新实例只是为了查询单个不相关的表是一种矫枉过正。
你怎么看？
【问题讨论】：
【发布时间】：2009-03-27 05:31:00
【问题描述】：
无论它管理多少个表，构建数据上下文并不昂贵，因此在决定是否拥有一个或多个单独的数据上下文实现时，这不应成为标准。一个新的数据上下文是“空的”，直到您真正开始使用它，并且根据需要创建表实例。
使数据上下文实例变得昂贵的原因是当您一遍又一遍地使用同一个实例来跟踪对不同对象的更改时 - 例如，在 ASP.NET 应用程序中使用缓存的数据上下文实例来执行所有数据库操作（现在这是不行的）。
只要您按预期使用数据上下文，在工作单元模式中，它可以在类定义级别管理多少表并不重要，因为您只需在当前工作单位。
对我来说，数据上下文在逻辑上代表目标数据库，因此它应该代表在该数据库中映射的所有实体，无论是 10 还是 100 - 将其拆分实际上并没有带来任何好处，除了更少的代码行一个给定的类，但如果这是你关心的东西，那么无论如何，有不同的类。
【讨论】：
-
谢谢。我不确定实例开销，所以我认为你已经很好地解决了这个问题。事实上，在这个项目中，我将动态数据用于管理目的，将 MVC 用于前端。我最终对两者都使用了相同的 LINQ-to-SQL 类，我想我会坚持下去。
取决于您拥有的桌子数量。如果它说小于，比如说，20，我个人不会拆分它。
如果您愿意，您可以按任务、关系或目的进行拆分。
由你决定，我会说，真的。我首先要记住的是“哪种方式最易于维护？”在决定是否拆分它们时。
【讨论】：