在我的数据库设计中，我倾向于拥有表的“集群”。这些集群通常支持一个应用程序或一组功能紧密相关的应用程序。通常，这些集群还通过相对少量的外键彼此相关;这有助于业务中的独立应用程序相互集成。
所以，例如：假设我有应用程序“Foo”，“Bar”和“Baz”，每个应用程序有几个表。这是表及其外键引用的列表：
目前，我正在使用LINQ-to-SQL来访问这些表。我为每个集群（Foo，Bar和Baz）都有一个单独的项目，并且每个项目都有一个.dbml用于集群中的所有表。这里的想法是使用集群的每个（一个或多个）应用程序可以导入包含它所需的LINQ类的共享库。
这可能是也可能不是一个好主意;它看起来像jury is still out。我真正想知道的是，我是否可以在另一个集群中的类表示的集群之间具有引用，即使它们存在于不同的上下文类中。 （更具体地说，如何在Visual Studio中创建此关系）。
回到这个例子，我想：
在门外，对上下文实体的所有引用都是简单的ID（int），而不是对象，并且根据上下文实体的集合根本不存在。我知道我可以将自己的方法添加到这些类中以进行适当的查找（给定上下文的实例），但我想让事情更精简一些。是一致的。
请注意，通过上下文/集群的这种分离，我可以在应用程序之间实现模块化。因此，例如，Baz应用程序只需要导入Baz和Foo上下文（因为Baz依赖于Foo），而不是Bar。 （这假设我在Foo中没有Bar实体的集合，这对我来说没问题）。这是一件好事，但并不重要：如果LINQ / VS不能简化这一点，那么我会考虑废弃模块化并采用一个大的上下文。
答案 0 :(得分：1)
L2S无法建模跨DBML文件的关系。 IMO，这是L2S的一个主要缺点。 我在申请中苦苦挣扎。我们将所有实体都放在单独的DBML文件中。每个DBML文件代表我们应用程序中的命名空间，以及SQL Server数据库中的Schema。
所以，我最终做的是每个具有在不同命名空间中表示外部关系的属性的实体，我在属性中将自定义关联属性放在部分类中，模仿L2S关联属性。此自定义属性允许我们自己管理关系。没有L2S那么高效，但它对我们来说效果很好。
兰迪