Linq to SQL - 设计问题

Question

嗨， 目前我有一个大的数据共享与35个表（我把我所有的数据库表拖到设计师）。我必须承认这非常舒适，因为我对我的完整数据库有ORM，并且使用linq查询非常简单。

我的问题是：1。 你会认为这是坏的设计有一个datacontext的35个表或我应该把它拆分到逻辑单元？ 2.使用如此大的数据上下文会有什么性能损失吗？

谢谢皮尼。

Answer 1

• 斯普利特逻辑单元
• 没有真正的性能损失寿这将是有点难以有概述。

Answer 2

由于在每次创建新上下文时重新构建所有映射的元模型，但是如果您正在监视此操作并且它不会导致您出现问题，那么我不会担心它。

我倾向于只使用DataContexts对于只需要模拟表了一把，从长远来看，在我看来，一个更传统的，成熟的ORM像NHibernate的去比什么都重要和更容易很小的项目。

Answer 3

我可以理解你的痛苦。 LINQ to SQL设计师对于大型模型来说并不好。但是35桌并不是很大。

当您可以在两个或更多个组，其中每个组是完全独立于其他（无关）的分割表中，在这种情况下，分裂IMO合理的，特别是当基团被逻辑上分开的部分。在这种情况下，你可以给每个上下文命名。

但是，当组之间存在关系时，通常表明它们是一个域的一部分。当分割这样一个域时，这意味着你将不得不复制表，这可能是恼人的和不切实际的，但是当一个模型/上下文只读取表时，它可能没问题。

另外请注意，拆分模型可能会在您的架构中产生一些烦人的副作用。当然这取决于你的架构。我一直在使用的应用程序使用'服务命令'来代表表示层执行业务逻辑。一个自动构造提供了一个DataContext实例的命令，并且有多个DataContext使得设计非常令人沮丧。