我已经阅读了Rick Strahl关于Linq to SQL DataContext Lifetime Management的文章,希望找到一些关于如何管理我的.dbml文件的答案,因为它们与DataContext密切相关.不幸的是,Rick的文章似乎主要关注运行时的DataContext生命周期,而我的问题是关于如何在设计时组织.dbml .
这里已经提出并回答了 ".dbml的最佳实践"的一般问题,答案主要集中在管理.dbml的外部工具上.
我想问一个更为集中的问题,即何时以及为什么在基于LINQ to SQL的项目中没有单个.dbml文件？
这个问题在LINQ to SQL .dbml最佳实践的问题中得到了解决,但我不确定如何添加问题.
我们的一个应用程序使用LINQ to SQL,我们目前有一个.dbml文件用于整个数据库,这个文件变得难以管理.我们正在考虑将它重构为更多模块/功能特定的单独文件,但是一个问题是许多高级类必须在几个.dbml文件中重复,因为这些关联不能跨越. dbml文件(据我所知),还有附加的部分类代码.
有没有人在努力解决这个问题,你会提出什么建议？
这可能只是一个是或否的问题类型,但无论如何...
从我见过的使用mvc的所有(大多数)示例中可以看出,创建dbml文件的方法只是将数据库的整个模式放入其中,并让它自动生成所有linq到sql的优点.看起来你只需要其中一个(因为你不能在同一个项目中的单独dbml文件中有重复的表),但由于某种原因,似乎有更好的方法来做到这一点......特别是当处理一个具有相当数量的表的大型项目.
那么这是创建一个在mvc项目中使用的dbml文件的正确方法,只需将整个表结构放入并转到城镇？如果没有,你是怎么做到的？