问题描述
我已经阅读了Rick Strahl在 SQL DataContext生命周期管理的Linq 希望找到有关如何管理.dbml文件的答案，因为它们与DataContext密切相关.不幸的是，尽管Rick的文章似乎专注于 DataContext在运行时的生存期，但我的问题与如何在设计时组织.dbml有关.
I've read Rick Strahl's article on Linq to SQL DataContext Lifetime Management hoping 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 runtime though, and my question is concerned with how the .dbml's should be organized at design time.
使用.dbml的最佳做法"的一般问题在这里被询问并得到答案，答案集中在管理.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.
我要问的是一个更集中的问题，即何时以及为什么不 在基于LINQ to SQL的项目中只有一个.dbml文件?
I'm asking a more focused question of when and why should you not have a single .dbml file in your LINQ to SQL based project?
推荐答案
请注意，LINQ2SQL用于处理与对象之间的数据库关系的简单方法.
Please note that LINQ2SQL is intended for simple and easy way to handle database relationship with objects.
不要通过创建多个.dbml文件来破坏表关系和工作单元概念.
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来处理存储过程
- 如果您不在乎工作单元的概念.
如果您的数据库太复杂，那么我会考虑使用ORM，例如NHibernate，EF 4
If your database is too complex, then I would consider ORM such as NHibernate, EF 4
这篇关于LINQ to SQL:每个项目多个/单个.dbml?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！