最好是拥有一个包含所有表的胖数据上下文类，还是将它们分解为较小的类并可能具有“单表”类？
从组织的角度来看，我觉得我不应该将关系分割到多个数据上下文(我什至认为这是不可行的)。但另一方面，我认为仅仅为了查询一个不相关的表而创建该胖类的全新实例是一种矫枉过正的行为。
你觉得怎么样？
最佳答案
无论管理多少个表，构建数据上下文并不昂贵，因此这不应该成为决定是否拥有一个或多个单独的数据上下文实现的标准。在您实际开始使用新的数据上下文之前，它是“空的”，并且会根据需要创建表实例。
当您一遍又一遍地使用同一个实例来跟踪不同对象的更改时，数据上下文实例会变得昂贵 - 例如，在 ASP.NET 应用程序中使用数据上下文的缓存实例来执行所有数据库操作(现在这是一个禁忌)。
只要您按预期使用数据上下文，在工作单元模式中，它可以在类定义级别管理多少个表并不重要，因为您只实例化您在工作单元中需要的表。当前的工作单元。
对我来说，数据上下文在逻辑上代表目标数据库，因此它应该代表该数据库中映射的所有实体，无论是 10 个还是 100 个 - 将其拆分实际上除了减少代码行数之外没有任何好处。一个给定的类，但如果这是你关心的事情，那么无论如何，有不同的类。
关于c# - LINQ to SQL 类，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/688658/