管理LINQ to SQL .dbml模型的复杂性

在LINQ to SQL .dbml最佳实践中，此问题已在一定程度上得到解决，但是我不确定如何添加到问题中。

我们的其中一个应用程序使用LINQ to SQL，并且我们目前对于整个数据库都有一个.dbml文件，该文件变得越来越难以管理。 我们正在考虑将其重构为更多的模块/功能特定的单独文件，但是一个问题是许多高级类必须在多个.dbml文件中重复，因为无法跨多个使用。 dbml文件(据我所知)，以及其他部分类代码。

有没有人解决这个问题，您会提出什么建议？

---

利用命名空间设置。您可以通过单击ORM的空白在属性中找到它。

这使我可以为一组业务规则设置一个Users表和一个User类，为另一组业务规则设置一个第二个(但是同一数据存储)Users表和一个User类。

或者，拆分库，这也应具有根据公司的命名约定更改命名空间的作用。我从来没有在需要访问每个表的企业应用程序上工作。

---

我也写了一个工具！ Mine用于使用C＃对dbml文件的更改进行脚本编写，因此您可以重新运行它们而不会丢失更改。请参阅我的博客http://www.adverseconditionals.com 4更多详细信息

---

超过一定大小后，使用xml代替dbml设计器可能会变得更加容易。

---

我已经编写了一个实用程序来解决该问题，我需要一个快速的应用程序来让您仅选择所需的数据库对象。就我而言，我经常需要一个复杂的视图，但是没有表格。

http://www.codeplex.com/SqlMetalInclude/

---

我们使用它来保留2个.dbml文件的方法。其中之一保存了存储的Procs，并且所有生产数据库访问都通过此操作完成。另一个位于单元测试文件夹中，其中包含表及其关系，用于DB数据操作和查询单元测试。

---