定义自定义产品类型的通用数据模型

Question

我想创建一个产品目录，其中包含目录中每种产品类型的复杂细节。产品类型与它们有很多不同的数据;一些只包含通用数据，一些包含一些额外的数据字段，一些包含许多特定于该产品类型的字段。我需要轻松地向系统添加新的产品类型并尊重他们的配置，我喜欢有关如何为这些产品设计数据模型以及如何处理持久性和检索的技巧。

有些产品非常通用，我打算使用通用用户界面来编辑这些产品。具有与之关联的可扩展配置的产品将获得为其编辑而创建的新视图（和控制器）。我希望所有自定义产品都定义了自己的模型，但是要共享一个共同的基类。基类将代表没有自定义字段的通用产品。

需要处理的示例产品：

1. 通用产品
   • 描述
2. 灯泡
   • 描述
   • 类型（带有荧光，白炽，卤素，LED的枚举）
   • 功率
   • 风格（泛滥，斑点等）
3. 冰箱
   • 描述
   • 请
   • 模型
   • 样式（在域模型中使用枚举）
   • 滤水器信息
     • 部件号
     • 描述

我希望使用MEF来发现系统中可用的产品类型。我计划创建包含产品类型模型，视图和控制器的程序集，将这些程序集放入bin中，让应用程序发现新的产品类型，并在导航中显示它们。

1. 使用SQL Server 2008，存储这些不同类型产品的最佳方法是什么，允许添加新类型而无需增加数据库架构？

2. 从数据库中检索数据时，将这些多态实体转换为正确的域模型的最佳方法是什么？

---

更新和澄清

1. 为了避免内部平台效应，如果每种产品类型都有一个数据库表（用于存储该类型的产品），那么我仍然需要一种方法来检索所有跨产品类型的产品。如何实现？

2. 我与Nikhilk更详细地讨论了他的SharePoint参考资料。具体来说，他在谈论这个问题：http://msdn.microsoft.com/en-us/library/ms998711.aspx。它看起来很有吸引力。无需解析XML;并且可以进行一些索引，允许对数据进行简单快速的查询。例如，我可以说“找到所有75瓦灯泡”，因为当行代表灯泡时，行中的第一个int列是瓦数。应用层中的某些东西（NHibernate？）将定义从产品类型到用户数据架构的映射。

3. 对具有属性表的架构进行投票，因为这可能会导致每个产品有很多行。这可能会导致索引困难，而且所有查询都必须基本上转移数据。

Answer 1

使用Sharepoint样式的UserData表，该表包含一组字符串列，一组int列等，以及一个Type列。

然后你有一个类型列表，它指定每种类型的模式 - 它的属性，以及它们在UserData表中映射到的特定列。

使用Azure和其他公用计算存储之类的东西，您甚至不需要定义表格。每个商店对象基本上都是字典。

Answer 2

我认为您需要使用像

这样的数据模型

产品表

• ProductId（PK）
• 产品名称
• 详细

属性表

• PropertyId（PK）
• ProductId（FK）
• ParentPropertyId（FK - 自我引用以对属性进行分类）
• 的PropertyName
• 的PropertyValue
• PropertyValueTypeId

属性值查找表

• PropertyValueLookupId（PK）
• PropertyId（FK）
• LookupValue

然后基于此获得动态视图。你可以使用PropertyValueTypeId coloumn来识别类型，使用约定，如（0-字符串，1-integer，2-float，3-images等） - 但最终你只能存储所有类型的无类型。您还可以使用此列选择控件模板，以将相应的属性呈现给用户。

您可以使用值查找表来保留特定属性的查找（以便用户可以从列表中选择）

Answer 3

总结让我们看看存储产品信息时所考虑的选项： 1）数据库中的一些xml格式

2）类似于上面关于具有x个类型定义列（sharepoint方法）的帖子

3）通过通用表，其中名称和类型定义存储在查找表中，次表中的值包含列id，propertyid，value（类似于＃2但是这种方法将提供无限的属性信息

4）上述选项的一些混合，其中product表将具有x个公共列（用于存储与所有产品共同的属性）和y用户定义的列（这可以是m的整数类型和n个varchar类型）。这可能是最好的＃2和正常结构，就像你知道所有产品的所有属性一样。您将获得最常用的属性（可能是所有产品中常见的属性）的最佳sql性能，同时仍允许每个产品的特定属性的自定义列。

还有其他选择吗？在我看来，我认为上面的4是组合中最好的混合。

• 戴夫

Answer 4

将尽可能多的共享预期结构放入传统的规范化3NF模型中，然后根据需要使用XML列进行扩充。

我没有看到MEF（或任何其他ORM）能够透明地完成所有这些工作。

Answer 5

我认为您应该避免使用Inner Platform Effect并为您的专业实体构建表格。您将编写特定的代码来管理它们，那么为什么没有适当的支持表呢？

它会使您的部署稍微困难 - 放入程序集并运行脚本 - 但从长远来看，它可能会为您节省很多痛苦。

Answer 6

杰夫，

我们目前在Products表中使用XML字段来处理所有特定于产品的数据。因此，我们的Products表有一些所有产品共享的常见字段，一个包含特定产品需要的XML，以及一些计算字段，这些字段可以抓取XML并将一些经常查询的字段作为“虚拟”字段显示在产品表（例如“Style”将设置为当前产品定义的任何值，如果产品没有Style属性，则设置为NULL。）

到目前为止，我们对这种方法非常灵活 - 如果为XML创建一些不错的XSD架构，您甚至可以为这些字段创建C＃代理类。

很适合我们 - 加入关系和XML世界的精华。

马克