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