设计服务对象是特定的还是通用的方法？

Question

方案：对WCF服务使用分层方法：商业服务将域/ DTO对象返回给客户端。 仍在开发中，因此我们可以打破合同。

人员对象具有名字和姓氏。 成员对象具有税号和出生日期。 这是因为在我们的域中，只有成员才能获得税号和出生日期。 使用此结构从服务取回数据时，很清楚哪些属性适用。

现在，我们介​​绍另一种可用于人的服务-假设是Employee。 在这种用法中，人员对象需要附加属性税文件编号和出生日期。

最好的进行方法是什么？

1）将Person对象视为通用Person并包含所有属性。 这可以将“人”映射到现实世界中的人，而不必基于用法。 这意味着返回“人”的服务将包括税号和出生日期，即使它们可能不相关。

2）将其他字段复制到Employee中。 这样可以使Person保持原样，并保持特定的服务调用，但要以重复为代价。

3）在我们之间为Member和Employee继承的对象之间创建另一个名为PersonWithDOBTFN的对象。 这消除了重复，使事情保持特定性，但引入了复杂性。

我真的在寻找一种设计这些对象的最佳实践方法。

Answer 1

您正在做的事情有问题-在各种情况下它都会崩溃。 仅从您的简短示例来看，最明显的情况就是某个人是否想成为成员和雇员。 当一个人不再想当雇员而只想再次当一个人怎么办？

雇员和成员不是真正的“是”概念。 我可能“成为”一名雇员或成员，但这并不是我真正的身份，也不是我作为一个实体的身份的基础。 成员和员工只是我们在成为人的过程中所扮演的众多角色中的两个。

不要用继承为角色建模，它不能很好地工作。 相反，只需拥有Person并添加一个Roles集合即可更改，支持一个人的多次参与等。

其余的。 映射属性在逻辑上所属的位置，而不是基于某种策略或先前的操作过程。 服务将返回您希望它们返回的任何内容，基础数据结构应具有逻辑性并防止重复。

Answer 2

我很想去

Person ---is-a---> Member ---is-a--> Employee

假定“员工”的工作方式与“成员”相比有明显不同。 您的问题中没有任何要表明的内容，但是我认为Employee中将有一些成员没有的其他功能。

关于您对复杂性的观点，我想说，在设计的这个阶段，这可能是您过早担心的事情。 对象层次结构的2个级别不仅不那么复杂-如果尝试分离逻辑，大多数体面大小的系统通常具有2个以上级别。 您对复杂性的观点是，随着系统的发展以及如果达到的水平使其变得更加复杂，您应该考虑的更多。