在我的 ASP.NET 应用程序中,我有一个 Person
和一个 PersonViewModel
。
我的 Person
是由 LinqToSql
生成的。它具有将持久保存在数据库中的属性。
我的 PersonViewModel
拥有 Person
拥有的一切,外加一对“选择列表”,它们将用于填充组合框,以及一个 FormattedPhoneNumber
(基本上是添加了破折号和括号的 PhoneNumber
)。
我最初只是让 Person
成为我的 PersonViewModel
的一个属性,但我认为这意味着页面必须“知道”某物是否是 Person
属性或 PersonViewModel
属性。例如,对于姓名, View 将请求 pvm.Person.Name
,但对于电话号码, View 将请求 pvm.FormattedPhoneNumber
。如果我使用继承,那么 View 所需的一切都将始终是 View 模型的直接属性,因此 pvm.Name
。
这听起来不错,但是,这里没有真正的“is-a”关系(即,我真的认为说“a PersonViewModel
is 一个 Person
),它似乎在面对“更喜欢组合而不是继承”的情况下飞翔。不过,我很难想到我需要换出能力的场景Person
代表其他东西。如果我这样做,它将不再是 PersonViewModel
。
你怎么说?继承 Person
还是将 Person
保留为属性(或完全为其他属性)?为什么?
更新
谢谢大家的回答。
看起来继承的想法几乎被普遍拒绝了,并且有一些合理的理由:
解耦类允许
ViewModel
包含仅域模型中需要的属性,以及任何其他属性。通过继承,您自然会公开域模型中的所有公共(public)属性,这可能不是一个好主意。ViewModel
不会因为域模型更改而自动需要更改。正如 Jay 提到的,解耦
ViewModel
有助于特定于 View 的验证。正如 Kieth 提到的,使用 Mapper(例如 AutoMapper)可以消除在类之间映射公共(public)属性的大量繁琐工作。
最佳答案
从对象派生意味着"is"关系。因此,在这种情况下,您实际上可以说 PersonViewModel
是一个 Person
。看起来这不太可能是你真正想要传达的语义,所以在这里使用组合而不是继承。
实际上它可能不会真正影响应用程序的可维护性(除了在这里和那里有更多的点)但是使用组合对我来说肯定感觉更干净。此外,如果它是 PersonViewModel
,那么大概 View 应该知道这是它正在处理的类型。
关于c# - PersonViewModel 继承自 Person - 聪明还是代码味?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2157605/