visual-studio LINQ to SQL：每个项目有多个/单个 .dbml？

LINQ to SQL: Multiple / Single .dbml per project?

提问by Dan Esparza

I've read Rick Strahl's article on Linq to SQL DataContext Lifetime Managementhoping to find some answers on how I would manage my .dbml files since they are so closely related to DataContext. Unfortunately, Rick's article seems to be focused on DataContext lifetime at runtimethough, and my question is concerned with how the .dbml's should be organized at design time.

我已经阅读了 Rick Strahl 关于Linq to SQL DataContext Lifetime Management的文章，希望能找到一些关于如何管理我的 .dbml 文件的答案，因为它们与 DataContext 密切相关。不幸的是，Rick 的文章似乎集中在运行时的 DataContext 生命周期，而我的问题是关于 .dbml 应该如何在设计时组织。

The general question of 'Best practices with .dbml's' has been asked and answered here, and the answers have focused on external tools to manage the .dbml.

已在此处提出并回答了“.dbml 的最佳实践”的一般问题，答案集中在管理 .dbml 的外部工具上。

I'm asking a more focused question of when and why should you nothave a single .dbml file in your LINQ to SQL based project?

我问的更集中的问题时，你为什么没有在你的LINQ to SQL基础项目单.dbml文件？

采纳答案by ashraf

Please note that LINQ2SQL is intended for simple and easy way to handle database relationship with objects.

请注意，LINQ2SQL 旨在以简单易行的方式处理数据库与对象的关系。

Do not break table relationship and units of work concepts by creating multiple .dbml files.

不要通过创建多个 .dbml 文件来破坏表关系和工作单元概念。

If you ever need to create multiple .dbml files (which i don't recommend), then try to satisfy the following:-

如果您需要创建多个 .dbml 文件（我不推荐），请尝试满足以下条件：-

1. If you create multiple databases with no relationship between those database tables.
2. If you want to use one of these .dbml just to handle stored procedures
3. If you do not care about unit of work concept.

1. 如果您创建多个数据库，而这些数据库表之间没有关系。
2. 如果您只想使用这些 .dbml 之一来处理存储过程
3. 如果你不关心工作单元的概念。

If your database is too complex, then I would consider ORM such as NHibernate, EF 4

如果你的数据库太复杂，那我会考虑ORM比如NHibernate，EF 4

回答by Guy

In my opinion, you can split the .dmbl files so that each hold a subset of tables/procs from a DB according to function and relationship. I have not done this yet so this is just opinion.

在我看来，您可以拆分 .dmbl 文件，以便每个文件都根据功能和关系保存来自数据库的表/过程的子集。我还没有这样做，所以这只是意见。

I have however created multiple .dbml files to assist with unit testing. If you work in an environment which restricts you to using stored procs in your production environment then you cannot use the table part of the .dbml (you can use the proc part though). So if you "unit test" (this is really integration testing) the DB layer of your code you can call the proc wrapper and then check the results by querying the tables through the .dbml interface. In cases like this I'll split the .dmbl file into just the tables that I want to query in my "unit test."

然而，我创建了多个 .dbml 文件来帮助进行单元测试。如果您在限制您在生产环境中使用存储过程的环境中工作，那么您不能使用 .dbml 的表部分（尽管您可以使用 proc 部分）。因此，如果您“单元测试”（这实际上是集成测试）代码的 DB 层，您可以调用 proc 包装器，然后通过 .dbml 接口查询表来检查结果。在这种情况下，我会将 .dmbl 文件拆分为我想在“单元测试”中查询的表。

Further info: I have 2 solutions that I build. One has unit tests and is never built on the build server. The other is built on the build server and deployed to test/production.

更多信息：我有 2 个我构建的解决方案。一个有单元测试，并且从来没有建立在构建服务器上。另一个构建在构建服务器上并部署到测试/生产。

回答by Filip Ekberg

I'd say, you always just need 1 dbml-file PER database. If you have multiple connections to other databases, consider design or use seperate dbml-files. Either way, one is enough per database.

我会说，你总是只需要 1 个 dbml-file PER 数据库。如果您与其他数据库有多个连接，请考虑设计或使用单独的 dbml 文件。无论哪种方式，每个数据库一个就足够了。

This because the dbml mapps to your tables and why not just use one "data connector" / "data layer" for that, seems odd / weird design to use more than one.

这是因为 dbml 映射到你的表，为什么不只使用一个“数据连接器”/“数据层”，使用多个看起来很奇怪/奇怪的设计。

It's probably more controllable using only 1 aswell.

也可能仅使用 1 个更易于控制。

回答by Kevin Craft

This issue has been thoroughly analyzed here: http://craftycode.wordpress.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/

这里已经彻底分析了这个问题：http: //craftycode.wordpress.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/

In summary, you should create at most one data context per strongly connected group of tables, or one data context per database.

总之，您应该为每个强连接的表组最多创建一个数据上下文，或者每个数据库创建一个数据上下文。

回答by Kevin Craft

Say you have a database:

假设你有一个数据库：

Database D contains tables A, B, C, X, Y, Z where

数据库 D 包含表 A、B、C、X、Y、Z，其中

• Table A has a foreign key relationship with tables B and C
• Table X has a foreign key relationship with tables Y and Z
• Table X also has a foreign key relationship with table A

• 表A与表B和C有外键关系
• 表 X 与表 Y 和 Z 有外键关系
• 表X也和表A有外键关系

Say you have 2 DBML files P and Q based on database D

假设您有 2 个基于数据库 D 的 DBML 文件 P 和 Q

• DBML File P contains entities A', B' and C' where A' is connected to B' and C' via associations.
• DBML File Q contains entities X', Y' and Z' where X' is connected to Y' and Z' via associations.

• DBML 文件 P 包含实体 A'、B' 和 C'，其中 A' 通过关联连接到 B' 和 C'。
• DBML 文件 Q 包含实体 X'、Y' 和 Z'，其中 X' 通过关联连接到 Y' 和 Z'。

AFAIK, there is no way for DBML files P and Q to contain an association between entities A' and X'. This is the single biggest problem with having multiple DBML files.

AFAIK，DBML 文件 P 和 Q 无法包含实体 A' 和 X' 之间的关联。这是拥有多个 DBML 文件的最大问题。

To my mind, a DBML file reflects the data-model represented by the tables and constraints on those tables in a database. If some tables or constraints are missing from a set of DBML files, then the set of DBML files do not accurately reflect the underlying database.

在我看来，DBML 文件反映了由表和数据库中这些表的约束表示的数据模型。如果一组 DBML 文件中缺少某些表或约束，则该组 DBML 文件不能准确反映底层数据库。

Going back to our example, if there was no relationship between tables A and X in database D, then one would be able to create 2 DBML files.

回到我们的例子，如果数据库 D 中的表 A 和 X 之间没有关系，那么可以创建 2 个 DBML 文件。

Generically speaking, one can have multiple DBML files if each DBML file contains all entities and relationships that are connected. Note that the converse is not a problem, i.e., one can have a single DBML file containing multiple groups of entities that are not related to each other by any associations.

一般而言，如果每个 DBML 文件包含连接的所有实体和关系，则可以有多个 DBML 文件。请注意，反过来不是问题，即可以有一个 DBML 文件，其中包含多个实体组，这些实体组之间没有任何关联。

回答by Kevin Craft

Another thing to bear in mind is that LINQ uses the DataContext to track the identities of the instances of entities it creates. Therefore, an entity representing a row in a table created by one instance of the DataContext class is not the same as one created by another, even if all the properties are the same.

要记住的另一件事是 LINQ 使用 DataContext 来跟踪它创建的实体实例的身份。因此，表示由 DataContext 类的一个实例创建的表中行的实体与由另一个实例创建的实体不同，即使所有属性都相同。

When one has multiple DBML files, then by necessity, there will be multiple instances of DataContexts, one for each DBML file. Therefore, entities can't be joined or shared from one DataContext to another.

当一个人有多个 DBML 文件时，根据需要，会有多个 DataContexts 实例，每个 DBML 文件一个。因此，实体不能从一个 DataContext 加入或共享到另一个。

This is applicable when an entity exists in both (or all) DBML files.

当实体存在于两个（或所有）DBML 文件中时，这适用。

回答by Kevin Craft

The answer is tricky because it's what the situation requires. I try to logically separate each DBML into contexts (after all, the DBML provides the DataContext functionality). So if my app has a single context, then it doesn't make sense for me to have a separate DBML for each table. Context is king when creating your DBML files is what I say.

答案很棘手，因为这是情况所需要的。我尝试在逻辑上将每个 DBML 分成上下文（毕竟，DBML 提供了 DataContext 功能）。因此，如果我的应用程序只有一个上下文，那么为每个表设置单独的 DBML 对我来说没有意义。创建 DBML 文件时，上下文为王是我所说的。