我读过Rick Strahl关于Linq to SQL DataContext Lifetime Management的文章，希望找到一些关于如何管理我的.dbml文件的答案，因为它们与DataContext密切相关。不幸的是，Rick的文章似乎主要集中在运行时的 DataContext生存期，而我的问题是关于如何在设计时组织.dbml。
“.dbml的最佳实践”has been asked and answered here的一般问题，答案主要集中在管理.dbml的外部工具上。
我问的是一个更有针对性的问题何时以及为什么不在基于LINQ to SQL的项目中有一个.dbml文件？
答案 0 :(得分：8)
请注意，LINQ2SQL旨在以简单方便的方式处理与对象的数据库关系。
不要通过创建多个.dbml文件来破坏表关系和工作单元概念。
如果您需要创建多个.dbml文件（我不建议这样做），请尝试满足以下条件： -
如果您的数据库太复杂，那么我会考虑ORM，例如NHibernate，EF 4
答案 1 :(得分：4)
在我看来，您可以拆分.dmbl文件，以便每个文件根据函数和关系从DB中保存表/ proc的子集。我还没有这样做，所以这只是意见。
但我创建了多个.dbml文件以协助进行单元测试。如果您在限制您在生产环境中使用存储过程的环境中工作，那么您不能使用.dbml的表部分（尽管您可以使用proc部分）。因此，如果您“单元测试”（这实际上是集成测试）代码的数据库层，您可以调用proc包装器，然后通过.dbml接口查询表来检查结果。在这种情况下，我会将.dmbl文件拆分成我想在“单元测试”中查询的表。
更多信息：我有2个解决方案，我建立。一个具有单元测试，并且永远不会在构建服务器上构建。另一个构建在构建服务器上并部署到测试/生产。
答案 2 :(得分：3)
我会说，你总是需要1个dbml-file PER数据库。如果您与其他数据库有多个连接，请考虑设计或使用单独的dbml文件。无论哪种方式，每个数据库就足够了。
这是因为dbml mapps到你的表，为什么不只是使用一个“数据连接器”/“数据层”，看起来奇怪/奇怪的设计使用多个。
仅使用1也可能更容易控制。
答案 3 :(得分：3)
此问题已在此处进行了详细分析：http://craftycode.wordpress.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/
总之，每个强连接的表组最多只能创建一个数据上下文，或者每个数据库创建一个数据上下文。
答案 4 :(得分：1)
假设你有一个数据库：
数据库D包含表A，B，C，X，Y，Z其中
假设您有2个基于数据库D的DBML文件P和Q
AFAIK，DBML文件P和Q无法包含实体A'和X'之间的关联。这是拥有多个DBML文件的最大问题。
在我看来，DBML文件反映了表和数据库中这些表的约束所代表的数据模型。如果一组DBML文件中缺少某些表或约束，则该组DBML文件无法准确反映基础数据库。
回到我们的例子，如果数据库D中的表A和X之间没有关系，那么就可以创建2个DBML文件。
一般来说，如果每个DBML文件包含所有连接的实体和关系，则可以有多个DBML文件。请注意，反过来不是问题，即，可以有一个DBML文件包含多个实体组，这些实体组之间没有任何关联。
答案 5 :(得分：0)
答案很棘手，因为这是情况所需要的。我尝试在逻辑上将每个DBML分成上下文（毕竟，DBML提供了DataContext功能）。因此，如果我的应用程序只有一个上下文，那么对每个表都有一个单独的DBML是没有意义的。在我创建DBML文件时，上下文是王道。
答案 6 :(得分：0)
要记住的另一件事是LINQ使用DataContext来跟踪它创建的实体实例的身份。因此，表示由一个DataContext类实例创建的表中的行的实体与另一个实例创建的实体不同，即使所有属性都相同。
当一个人拥有多个DBML文件时，必然会有多个DataContexts实例，每个DBML文件一个。因此，无法将实体从一个DataContext连接或共享到另一个DataContext。
当两个（或所有）DBML文件中都存在实体时，这是适用的。