LINQ :每个项目多个/单个.dbml？

Question

我读过Rick关于Linq到SQL DataContext生命周期管理的文章，希望能找到一些关于如何管理.dbml文件的答案，因为这些文件与DataContext关系非常密切。不幸的是，Rick的文章似乎集中在运行时的DataContext生存期，我的问题是如何在设计时组织..dbml。

“使用. .dbml的最佳实践”已经在这里被询问和回答了的一般问题以及答案集中在管理.dbml的外部工具上。

我在问一个关于的更集中的问题，为什么而不是在基于LINQ的项目中有一个.dbml文件

Answer 1

请注意，LINQ2SQL的目的是为了简单方便地处理与对象的数据库关系。

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

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

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

如果您的数据库太复杂，那么我会考虑ORM，例如NHibernate、EF 4

Answer 2

在我看来，您可以拆分.dmbl文件，以便每个文件根据函数和关系从DB中保存一个表/procs的子集。我还没有这样做，所以这是公正的意见。

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

进一步的信息:我有两个解决方案，我构建。一个有单元测试，从来没有构建在构建服务器上。另一个构建在构建服务器上，并部署到测试/生产中。

Answer 3

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

这是因为对您的表使用dbml，以及为什么不为此使用一个“数据连接器”/“数据层”，因此使用多个数据连接器的设计似乎很奇怪。

它可能更容易控制，只使用1。