Question

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

库存项目类型：

硬件
- PC
- - 桌面
- - 服务器
- - 笔记本
- 附件
- - 输入（键盘，扫描仪等）
- - 输出（显示器，打印机等）
- - 存储（USB记忆棒，磁带机等）
- - 通讯（网卡，路由器等）
软件

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

感觉应该有一个非常简单，优雅的解决方案，但我不能把手指放在它上面。任何帮助或投入表示赞赏！

Answer 1

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

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 2

你的问题的要点与ORM没什么关系，这只是一个如何为你的需求建立一个良好的关系模型的问题。并且你给了自己答案：如果你不想为每个枚举建模一个不同的表，那就不要这样做了。对您的PC类型，附件类型等使用整数attribut，并将其映射到代码中定义的枚举。这样，无论何时扩展其中一个枚举，您都不必更改数据库中的任何内容（甚至不包括任何枚举表中的数据）。

当然，有些情况下，将枚举建模为单独的表是有好处的。显然，当您必须将额外数据存储到枚举（例如短名称，长名称，ID等）时就是这种情况。或者当你有不同的程序时，可能使用不同的编程语言，这些都需要处理同一组枚举。或者当用户应该能够扩展PC类型列表而无需新程序版本时。

Answer 3

我认为这需要复合设计模式：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 4

这很难“荒谬地规范化” - 事实上，单个自引用表足以使用邻接列表模型将信息保存在数据库中：

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; }
}

这就是你所要做的一切。如果您开始拥有非常深/宽的层次结构，那么您可能需要考虑替代性能模型，但是在这里给出了示例，您距离简单的邻接列表还有很长的路要走。

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

我怎样才能最好地解决这种对象类型的heirachy？某种枚举层次结构？

4 个答案: