1

在我的数据库设计中，我倾向于使用表的“集群”。这些集群通常会支持一个应用程序或一组功能紧密相关的应用程序。通常，这些集群还通过相对较少数量的外键相互关联；这有助于业务中原本独立的应用程序相互集成。

因此，例如：假设我有应用程序“Foo”、“Bar”和“Baz”，每个应用程序都有几个表。这是表及其外键引用的列表：

  • FooTableOne
  • FooTableTwo -> FooTableOne
  • BarTableOne -> FooTableTwo
  • BarTableTwo -> BarTableone
  • BazTableOne
  • BazTableTwo -> FooTableTwo，BazTableOne

目前，我正在使用 LINQ-to-SQL 来访问这些表。我为每个集群（Foo、Bar 和 Baz）都有一个单独的项目，并且每个项目都有一个用于集群中所有表的 .dbml。这里的想法是，使用集群的每个（一个或多个）应用程序都可以导入一个包含它需要的 LINQ 类的共享库。

这可能是一个好主意，也可能不是一个好主意；看起来陪审团 还 没有 出来。我真正想知道的是，我是否可以拥有由另一个集群中的类表示的集群之间的引用，即使它们存在于不同的上下文类中。（更具体地说，如何在 Visual Studio 中创建这种关系）。

回到这个例子，我想要：

  • 富项目
    • Foo.dbml
    • FooDataContext
    • FooTableOne
      • FooTableOne.FooTableTwos
    • FooTableTwo
      • FooTableTwo.FooTableOne
      • FooTableTwo.BarTableOnes（这个没那么重要）
      • FooTableTwo.BazTableTwos（这个没那么重要）
  • 项目栏
    • 条形图.dbml
    • 条形数据上下文
    • 吧台一号
      • BarTableOne.FooTableTwo
      • BarTableOne.BarTableTwos
    • 酒吧桌二
      • BarTableTwo.BarTableOne
  • 巴兹计划
    • Baz.dbml
    • BazDataContext
    • BazTableOne
      • BazTableOne.BazTableTwos
    • BazTableTwo
      • BazTableTwo.FooTableTwo
      • BazTableTwo.BazTableOne

在门外，对上下文外实体的所有引用都是简单的 ID（整数），而不是对象，而且对上下文外实体的集合根本不存在。我知道我可以将自己的方法添加到这些类中以进行适当的查找（给定上下文的实例），但我想让事情变得更加精简和一致。

请注意，通过上下文/集群的这种分离，我获得了应用程序之间的模块化。因此，例如，Baz 应用程序只需导入 Baz 和 Foo 上下文（因为 Baz 依赖于 Foo），而不是 Bar。（这假设我在 Foo 中没有 Bar 实体的集合，这对我来说很好）。这是一件好事，但并不重要：如果 LINQ/VS 不能让这变得容易，那么我将考虑放弃模块化并使用单一上下文。

4

1 回答 1

1

L2S 无法对跨 DBML 文件的关系进行建模。IMO，这是 L2S 的一大缺点。我在我们的应用程序中遇到了这个问题。我们在单独的 DBML 文件中拥有所有实体。每个 DBML 文件代表我们应用程序中的一个命名空间，以及我们 SQL Server 数据库中的一个模式。

所以，我最终做的是对于每个在不同命名空间中具有表示外部关系的属性的实体，我在部分类中的属性上放置了一个自定义关联属性，它模仿 L2S 关联属性。这个自定义属性允许我们自己管理关系。没有 L2S 那样高效，但它对我们来说效果很好。

兰迪

于 2009-11-25T00:24:08.117 回答