我如何最好地解决这个对象类型层次结构？某种枚举层次结构？

Question

我很好奇是否有任何解决方案可以在 ORM 方法中解决对象层次结构（在本例中，使用实体框架 4）。我正在研究 EF4 上的一些文档，并尝试将其应用于简单的库存跟踪程序。库存可能属于的类型如下：

库存项目类型：

• 硬件
• • 电脑
  电脑
• • • 桌面
• • • 服务器
• • • 笔记本电脑
• • 配件
• • • 输入（键盘、扫描仪等）
• • • 输出（显示器、打印机等）
• • • 存储（U 盘、磁带驱动器等）
• • • 通信（网卡、路由器等）
• 软件

在这种情况下处理枚举有哪些建议？枚举是解决方案吗？我真的不想为这样一个相对简单的实验建立一个可笑的标准化数据库（例如 InventoryType、InventorySubtype、InventoryTypeToSubtype 等的表）。我真的不想让我的数据模型变得过于复杂，即使没有包含其他属性或方法，每个子类型都会被继承（除了 PC 类型，理想情况下会有相关的附件和软件，但这可能超出了这里的范围）。

感觉应该有一个非常简单、优雅的解决方案，但我无法具体说明。任何帮助或意见表示赞赏！

Answer 1

我认为这需要复合设计模式： http://www.dofactory.com/Patterns/ PatternComposite.aspx

的代码如下：

class InventoryItem
{
    public string Name { get; private set; }
    public InventoryItem Parent { get; private set; }
    public IList<InventoryItem> Children { get; private set; }
}

HTH。

Answer 2

您可以使用类型层次结构...

public interface IInventoryType
{
    string Name { get; }
}

public class Hardware : IInventoryType
{
    public string Name { get { return "Hardware"; } }

    public class PC : IInventoryType
    {
        public string Name { get { return "PC"; } }

        public class Desktop : IInventoryType
        {
            public string Name { get { return "Desktop"; } }
        }

        public class Server : IInventoryType
        {
            public string Name { get { return "Server"; } }
        }
    }
}

然后使用它们可能看起来像这样...

IInventoryType invType = new Hardware.PC.Server();

if (invType is Hardware.PC.Server)
{
     Console.WriteLine("Yes!");
}
else
{
     Console.WriteLine("No!");
}

虽然它会起作用，但我不确定它是否有意义。这很容易变得复杂且难以维护。

这可能更适合作为数据存储在数据库中，并编写代码以通用方式（而不是特定方式）处理数据。

每次添加新类型时，您都需要更改代码，这并不理想。

Answer 3

这很难说是“可笑的标准化” - 事实上，单个自引用表足以使用邻接列表模型将信息保存在数据库中：

Categories (CategoryID, CategoryName, ParentCategoryID)

其中 ParentCategoryID 引用 CategoryID 在同一张桌子上。

这可以映射到一个非常简单的实体类：

public class Category
{
    public string Name { get; set; }
    public Category ParentCategory { get; set; }
    public IList<Category> ChildCategories { get; set; }
}

这实际上就是您所要做的一切。如果您开始拥有非常深/宽的层次结构，那么您可能需要考虑替代模型来提高性能，但鉴于此处的示例，您距离超出简单邻接列表还有很长的路要走。

忘记枚举——它们在这里没有意义。如果这是一个数据驱动的应用程序，您几乎肯定希望能够在不更改代码的情况下更改类别列表，而枚举类型需要您这样做。

Answer 4

你的问题的要点与ORM没有太大关系，它只是一个如何为你的需求建立一个好的关系模型的问题。您已经给了自己答案：如果您不想为每个枚举建模不同的表，请不要这样做。对您的 PC 类型、配件类型等使用整数属性，并将其映射到代码中定义的枚举。这样，每当您扩展某个枚举时，您都不必更改数据库中的任何内容（甚至不需要更改任何枚举表中的数据）。

当然，在某些情况下，将枚举建模为单独的表是值得的。显然，当您必须向枚举存储附加数据（如短名称、长名称、ID 等）时，就会出现这种情况。或者当您有不同的程序时，可能使用不同的编程语言，它们都需要处理同一组枚举。或者当用户应该能够扩展 PC 类型列表而不需要新版本的程序时。