0

我一直在为这个项目遵循主要是 DDD 方法，所以，像任何 DDD'er 一样，我首先创建了我的域模型类。我的意图是将这些 POCO 用作我的 LINQ-to-SQL 实体（是的，它们不是纯 POCO，但我可以接受）。我已经开始创建数据库模式和外部映射 XML 文件，但是在建模实体的关系和关联时遇到了一些问题。

工件代表一个文档。工件可以与任务或案例相关联。Case 实体如下所示：

public class Case 
{
     private EntitySet<Artifact> _Artifacts;
     public IList<Artifact> Artifacts
     {
          get
          {
               return _Artifacts;
          }
          set
          {
               _Artifacts.Assign(value);
          }
     }
     .
     .
     .
}

由于 Artifact 可以与 Case 或 Task 相关联，因此我可以选择在 Artifact 类上使用继承来创建 CaseArtifact 和 TaskArtifact 派生类。然而，这两个类之间的唯一区别是是否存在案例字段或任务字段。当然，在数据库中，我将有一个表 Artifact，其中包含类型鉴别器字段以及 CaseId 和 TaskId 字段。

我的问题：这是解决此问题的有效方法，还是为每个关联（总共 2 个新表）创建一个连接表是更好的方法？

4

2 回答 2

2

我可能会使用两个表 - 它使引用完整性-PK/FK 在数据库中的处理更简单一些，因为您不必有基于选择器列的复杂约束。

（回复您的评论 - 我的空间不足，所以在这里发布作为编辑）我的总体理念是数据库应该使用数据库最佳实践建模（保护您的周边并确保数据库一致性，使用尽可能多的 RI 和约束，通过 SP 提供所有访问，根据需要记录活动，控制所有访问模式，在必要时使用触发器）并且对象模型应使用 OOP 最佳实践建模，以提供强大且一致的 API。处理阻抗不匹配是您的 SP/数据访问层的工作。

如果您只是将设计良好的对象模型持久化到数据库中，那么在不通过对象模型的镜头查看时，您的数据库将没有太多内在价值（难以进行数据挖掘、报告、仓库、元数据模糊等） -这对于某些应用程序来说很好，通常不适用于我的应用程序。

如果您只是在应用程序中模仿设计良好的数据库结构，而不提供丰富的 OO API，那么您的应用程序将难以维护，并且内部结构将难以处理 - 通常非常程序化、僵化且代码量很大复制。

于 2009-11-16T19:23:43.477 回答
1

我会考虑在case和task之间找到共同点，因为没有更好的词，我们称之为“ CaseTask ”，然后从那个词中进行子类型（继承）。之后，您将文档附加到超类型。

更新（评论后）：
然后我会考虑这样的事情。每个文档可以附加到多个案例或任务。



artifact_model_01D

于 2009-11-16T20:09:10.220 回答