深层继承层次结构的替代方案?

Zac*_*zic 6 language-agnostic oop orm inheritance domain-driven-design

我试图用一组综合属性对产品进行建模.通常,在线商店会使用文本描述来列出特定产品的属性.但是,这种解决方案并不是最佳的.

例如,以下链接显示了同一产品的文本描述中属性的不一致性,但是对于不同的制造商:

因此,我选择了一个继承层次结构如下:

Product> Component> GraphicsCard>NvidiaGraphicsCard

这是因为我希望对每个属性进行细粒度的控制Product.这允许我包含特定于NvidiaGraphicsCard不适用于a的属性ATiGraphicsCard.

请注意,除了向子类添加更多字段之外,继承还允许我在OrderItem保持对a的引用方面使用多态Product.这就是我排除构图的原因.

拥有如此深层次的继承层次结构是否存在问题,如果有,是否有任何解决方案或模式来处理此问题?

eul*_*rfx 8

由于某些原因,深层继承层次结构在DDD和ORM的上下文中存在问题.当您尝试定义实体的身份时,会出现一个问题.A Product必须与基于身份的其他产品相比,无论哪个子类进行比较.可以在Product类中提供此功能,但必须注意确保也可以比较子类并且存在一些问题.例如,NHibernate将为类生成代理,因此对象的实际运行时类型不会是NvidiaGraphicsCard继承自它的代理.虽然瞬态实例NvidiaGraphicsCard不会成为代理.这意味着您无法根据类型进行比较.

另一个困难是配置ORM映射以支持继承.虽然大多数ORM允许它,但生成的映射和生成的SQL通常很复杂.您是否将所有子类存储在一个表中?在具有常用产品表的外键的多个表中?在前者你最终得到一个巨大的桌子.在后一种情况下,您的查询将受到影响,因为需要连接所有子类表.关系模型和对象模型之间存在太多的阻抗不匹配.事件如果使用文档数据库,最好支持组合而不是继承.

相反,我会选择一个Product类,它可以由产品特定描述符或属性字典组成.这将OrderItemProduct不知道特定产品类型的情况下引用a - 不需要多态性.这也可以更容易地允许新类型的产品 - 无需创建新的子类.