实体设计和继承

我正在考虑为更大的应用程序设计实体基类，并希望得到一些意见。主要是如果指定的是必须完成的方式或者是否有更简洁的方式。实体设计和继承

在解决方案中，我有一些baseclass所有实体将继承的变体。关系可以如下规定：

EntityBase//the primary baseclass containing name and id + other stuff 
NestedEntityBase:EntityBase //(if class will be able to contain lists of itself) 

VersionedEntityBase:EntityBase //(Some parameters specific for versioned entities) 
VersionNestedEntityBase:NestedEntityBase// (versioned AND nested) 

CurrentStateEntityBase:VersionedEntityBase// (the currentstate objects) 
VersionStateEntityBase:VersionedEntityBase// (old objects, saved when surrentstate objects change) 

CurrentStateNestedEntityBase:VersionNestedEntityBase// (the currentstate objects) 
VersionStateNestedEntityBase:VersionNestedEntityBase //(old objects, saved when surrentstate objects change)

这不幸的是，由于多重继承不可能产生一些代码重复。

它还将设置通用服务和通用控制器基类的分区。

这是它必须如何处理，或者我错过了一些更有效地做到这一点的聪明方式？

来源

2013-07-04 Baserz

如果它将包含自身的列表，为什么不将'Nested'命名为'List'！也可以使用接口 – Anirudha

Nested类包含的两个部分是它自己类型（命名版本）和它自己类型的Current属性（实体代码优先）的icollection。 CurrentState和VersionSTate做类似的事情，但是版本包含它自己类型的Parent和它自己类型的icollection'Children'。我同意接口（我使用），他们给了我更多的选择。但我的主要问题是如何用尽可能少的代码重复填充接口实例。但我找不到一种方法来避免重复，上层的entitybase属性将不得不重复。 – Baserz

但在这种情况下也许是不可避免的？ – Baserz

如何装饰设计模式：http://en.wikipedia.org/wiki/Decorator_pattern

它允许一些新的行为扩展的类层次结构不用每次都重复这整个层次结构。它还增加了在运行时扩展行为的好处（不仅在编译时）。

来源

2013-07-06 17:47:35 plw

删除我的评论，因为它是不正确的，我乍一看误解decoratorpattern。我同意在某些情况下它可能是一个选项，但由于这涉及数据库实体继承，所以我无法看到实现这种模式的一种好方法（至少现在）。对于其他地区，虽然我可以看到这一点的用处。 – Baserz

实体设计和继承

回答

相关问题