将ViewModel与Model完全相同是个好主意吗

我的解决方案中包含以下几层：

1. 应用域
2. 应用服务
3. App.Core（也许您将此称为App.DataLayer）
4. App.Web

软件设计模式不是我的问题，我有以下模型 Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

我想在视图（例如主页）上使用此模型，并且要使用Id, Name & Value，因此，如果要创建ViewModel，我将添加以下内容：

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

那么，这是个好主意吗？或只是使用Foo代替FooViewModel？

最初看起来似乎违反了DRY规则，但我认为，“相似甚至相同的代码”如果执行不同的操作或能够独立更改，则不一定是“重复”。在视图模型的情况下，代码定义的是“客户”所看到的内容，而不一定是企业所谈论的实体和操作。因此，您经常向客户端或接口揭示“偶然相同”的模型。您可以彼此独立地更改业务规则和条款或最终用户术语。

所以，我将把这个问题再次转给您。如果域发生更改，“版本1”客户端继续使用旧接口是否可以接受？您是否会在界面中显示不属于“核心业务规则”的条款或操作？反之亦然？

考虑到这些问题，如果您的视图的“功能”严格是为了揭示底层域模型，是的，这似乎违反了DRY规则。

_{还要记住，在某些具有成员属性和反映的语言中，也可以公开通过模型更改更自然地进行更改的视图。（或者通过其他聪明事而减少重复……但是，“聪明”常常无法证明重复是合理的，它可以为您省去很多时间。）}

我将拥有仅包含一个属性（一个Foo实例）的视图模型。这样，您就不会违反DRY的任何定义，如果Foo发生更改，则视图模型会自动看到更改，并使自己不受视图模型与模型的直接联系。

如果明天需要视图和Foo一起显示其他内容，则可以添加一个新属性，并且视图模型的意图仍然很清楚，它包含一个Foo和其他内容，您将不需要Foo的属性与其他不相关的属性的混合物。

我不会将您的视图模型认为是FooViewModel，而是根据视图应该显示的内容来考虑。如果仅显示一个Foo，则视图模型包含一个属性，一个Foo。

不知道我是否清楚地解释了这一点。如果没有，请告诉我，我会在醒着时尝试重新命名！

我会说FooViewModel以这种方式使用违反了DRY主体。当您需要进行更改时，Foo还必须对进行更改FooViewModel。我认为将其Foo用作视图模型会更好。如果您需要显示Foo中的内容以及其他内容，我将考虑使用视图模型。例如，假设您需要同时从Foo和渲染一些信息Bar。