将服务对象设计为具体还是通用的方法？答案

【问题标题】：Approach to design service objects to be specific, or generic?将服务对象设计为具体还是通用的方法？
【发布时间】：2010-11-17 03:47:42
【问题描述】：

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

Person 对象有名字和姓氏。会员对象有税号和出生日期。这是因为，在我们的域中，只有会员才能获得税号和出生日期。当使用这种结构从服务中取回数据时，可以清楚地知道哪些属性是适用的。

现在，我们介绍另一种用于个人的服务 - 比如说员工。在这种用法中，person 对象需要附加属性税号和出生日期。

最好的方法是什么？

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

2) 将附加字段复制到 Employee 中。这使 Person 保持原样，并以重复为代价保持服务调用的特定性。

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

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

【问题讨论】：

【解决方案1】：

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

Employee 和 Member 不是真正的“是”概念。我可能“是”一名员工或成员，但这并不是我真正的身份，也不是我作为一个实体的身份的基础。 Member 和 Employee 只是我们在成为 Person 过程中所占据的大量角色中的两个。

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

其余的 ehhh。将属性映射到它们在逻辑上属于的位置，而不是基于某种策略或先前的行动方案。服务返回你希望它们返回的任何东西，底层数据结构应该是合乎逻辑的并防止重复。

【讨论】：

【解决方案2】：

我很想去

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

这是假设“员工”的工作方式与“成员”相比存在明显不同。您的问题中没有任何内容表明这一点，但我认为 Employee 中会有一些 Member 没有的附加功能。

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

【讨论】：