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

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

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

现在，我们介绍另一个服务，它有一个针对个人的用法，比如说员工。在这种用法中，person对象需要附加属性tax file number和出生日期

最好的方法是什么

1） 将Person对象视为泛型Person，并包含所有属性。这会将人映射到真实世界的人，不一定基于使用情况。这意味着返回人员的服务将包括税务文件编号和出生日期，即使它们可能不相关

2） 将其他字段复制到Employee中。这使人员保持原样，并以重复为代价保持服务呼叫的特定性

3） 为Member和Employee创建另一个名为PersonWithDOBTFN的中间对象，该对象是我们从中继承的。这消除了重复，使事情具体化，但增加了复杂性

---

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

我很乐意接受

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

这是假定“雇员”的工作方式与“成员”的工作方式有明显不同。在你们的问题中并没有任何东西表明这一点，但我认为在员工中会有一些其他的功能，而这个成员并没有

---

关于你关于复杂性的观点，我想说，在设计的这个阶段，这可能是你过早担心的事情。对象层次结构的两个级别并不是那么复杂-如果您尝试分离逻辑，大多数大小适中的系统通常有两个以上的级别。你关于复杂性的观点是，随着系统的发展，如果它达到了比这复杂得多的程度，你应该更多地考虑它。

你所做的有一个问题——它会在各种情况下崩溃。从你的简单例子中，最明显的例子就是一个人想成为一名会员和员工。如果一个人不再想成为一名员工，而是想再次成为一名普通人，那该怎么办

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

不要用继承为角色建模，因为它不能很好地工作。取而代之的是，只需要一个人，并添加一个角色集合，该集合可以更改、支持一个人的多个参与，等等

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