PersonViewModel 继承自 Person - 聪明还是代码味道？

Question

在我的 ASP.NET 应用程序中，我有一个 Person 和一个 PersonViewModel。

我的Person 是由LinqToSql 生成的。它具有将持久保存在数据库中的属性。

我的PersonViewModel 拥有Person 所拥有的一切，加上几个“选择列表”，它们将用于填充组合框，以及一个FormattedPhoneNumber（基本上是一个带有破折号和括号的PhoneNumber添加）。

我最初只是在我的PersonViewModel 上创建了Person 属性，但我认为这意味着页面必须“知道”某个东西是Person 属性还是PersonViewModel 属性。例如，对于姓名，视图将请求pvm.Person.Name，但对于电话号码，视图将请求pvm.FormattedPhoneNumber。如果我使用继承，那么视图所需的一切都将始终是视图模型的直接属性，因此pvm.Name。

这听起来不错，但是这里没有真正的“is-a”关系（即，我认为说“a PersonViewModel is a @987654337 @)，而且它似乎在“更喜欢组合而不是继承”的情况下飞行。不过，我很难想到我需要能够将Person 换成其他东西的能力。如果我这样做，它将不再是PersonViewModel。

你说什么？从Person 继承或将Person 保留为属性（或完全其他）？为什么？

更新

感谢大家的回答。

看起来继承的想法几乎被普遍拒绝了，并且出于一些合理的原因：

1. 解耦类允许ViewModel 仅包含来自域模型的所需属性以及任何其他属性。通过继承，您自然会从域模型中公开所有公共属性，这可能不是一个好主意。

2. ViewModel 不会因为域模型更改而自动更改。

3. 正如 Jay 所说，解耦 ViewModel 有助于特定于视图的验证。

4. 正如 Kieth 所提到的，使用 Mapper（例如 AutoMapper）可以消除在类之间映射公共属性时的大量繁琐工作。

Answer 1

从对象派生意味着“是”关系。所以在这种情况下，您实际上会说PersonViewModel 是Person。看来这不太可能是您真正想要传达的语义，所以在这里使用组合而不是继承。

实际上，它可能不会真正影响应用程序的可维护性（除了在这里和那里有更多的点），但使用组合对我来说确实感觉更干净。此外，如果它是PersonViewModel，那么大概视图应该知道它正在处理的类型。

Answer 2

将Person 设为私有成员，并在PersonViewModel 中公开您的视图所需的属性，即使这些属性只是通过Person 的相应属性。

pvm.Person.Name 是这里的代码味道。

---

编辑：

您还将自己限制在客户端验证和/或域模型中的验证，后者意味着如果您为 Person 创建第二个或后续 ViewModel，则无法更改对 Person 成员的验证。 （嗯，你可以，但是这违反了开放-封闭原则，并且你将视图关注点引入到域中。）通过从视图中隐藏你的域对象，你给自己一个干净的空间来执行用例-在对域对象进行更改之前进行特定验证。域对象可能有自己的一组验证器，但它们可以严格适用于域，而不会出现特定于视图的问题。

Answer 3

您不应从 Person 继承或使用组合在 PersonViewModel 上拥有 Person。相反，您应该将所需的属性添加到 PersonViewModel 并在它们之间进行映射。 AutoMapper (http://www.codeplex.com/AutoMapper) 之类的工具让这一切变得非常简单。

出于多种原因，您不应将域模型直接暴露给视图，包括安全性（发布不足和过度发布）。

Answer 4

我认为这里的部分课程可能会更好。保留生成的 Person 类并添加另一个包含额外内容的部分 Person 类。

Answer 5

一方面：

如果你这样做了呢？

Person p = new PersonViewModel { //init some properties };

p 会做你希望Person 做的所有事情吗？如果可以，那么肯定会使用继承。如果它有一些与它实际上是 PersonViewModel 而不是 Person 的事实相关的特殊性，那么使用组合。

另一方面：

我倾向于使用继承来避免大量重复代码。由于您只是从一个父母继承给一个孩子（而不是多个孩子），因此您一开始并没有避免大量重复的代码。所以使用继承可能不值得。

Answer 6

我使用过的一个技巧，不是专门针对 ASP.NET MVC，而是针对类似的用例，是创建一个类，该类专门包含特定于 ViewModel 类的那些项目（即那些不只是通过隧道连接到person 类），并在 Person 类上提供扩展属性以允许访问扩展属性。这并不是严格意义上的经典视图模型，但我认为它允许许多相同的功能，而不会引入尴尬的继承或带有隧道属性的代码重复。

下面是我所说的一个简单示例：

public static class PersonExtensions {
   public PersonViewData ViewData(this Person p) {
       return new PersonViewData(p);
   }
}

public class PersonViewData {
     public PersonViewData(Person p) {
         this._person = p;
     }

     private Person p;

     public string FormattedPhoneNumber {
         get { return p.PhoneNumber.ToPrettyString(); // or whatever }
     }
}