设计服务对象的方法是具体的，还是通用的？
场景:对WCF服务使用分层方法:业务服务向客户端返回域/ DTO对象。还在开发中，所以我们可以打破合同。
Person对象有名字和姓氏。成员对象有税档号和出生日期。这是因为，在我们的域中，只有成员才能获得税务文件编号和出生日期。当使用这种结构从服务中获取数据时，可以清楚地知道哪些属性是适用的。
现在，我们引入另一个服务，它的用法是person -假设是Employee。在此用法中，person对象需要附加属性tax文件编号和出生日期。
继续的最佳方式是什么？
1)将Person对象视为通用Person，并包含所有属性。这将人映射到现实世界中的人，而不一定是基于使用。这意味着返回人员的服务将包括税务文件编号和出生日期，即使它们可能不相关。
2)将附加字段复制到Employee中。这使得Person保持原样，并以重复为代价保持特定的服务调用。
3)为Member和Employee创建另一个中间对象PersonWithDOBTFN。这消除了重复，保持了特定的东西，但引入了复杂性。
我真的在寻找一种设计这些对象的最佳实践方法。
回答 2
Stack Overflow用户
发布于 2010-11-17 15:32:29
你正在做的事情有一个问题--它在各种情况下都会崩溃。最明显的例子就是，如果一个人既想成为会员，又想成为员工。如果一个人不再想成为一名员工，而只是想再次成为一个人，那该怎么办呢？
员工和成员是不真实的“是一个”的概念。我可能“是”一名员工或成员，但这并不是我真正的身份，也不是我作为一个实体的身份的基础。Member和Employee只是我们在作为一个人的过程中所扮演的大量角色中的两个。
不要使用继承来建模角色，它不能很好地工作。相反，只需拥有Person并添加一个角色集合，该集合可以更改，支持一个人的多个参与等。
剩下的哦。将属性映射到它们逻辑上所属的位置，而不是基于某种策略或以前的操作过程。服务返回您希望它们返回的任何内容，底层数据结构应该是符合逻辑的，并防止重复。
Stack Overflow用户
发布于 2010-11-17 13:20:00
我很想跟你一起去
Person ---is-a---> Member ---is-a--> Employee这是假设"Employee“与"Member”的工作方式有明显的不同。在你的问题中没有任何东西表明这一点，但我假设在Employee中会有一些成员没有的额外功能。
关于你关于复杂性的观点，我想说，在你设计的这个阶段，这可能是你过早担心的事情。对象层次结构的2级并不是那么复杂--如果你尝试分离逻辑，那么最合适规模的系统通常有2级以上。你关于复杂性的观点是，随着系统的增长，如果它达到了比现在复杂得多的程度，你应该更多地考虑这一点。
https://stackoverflow.com/questions/4201297
复制相似问题
腾讯云开发者
