看起来我创建的ViewModels与其他类非常相似，并且它们似乎需要大量的代码重复，例如在当前项目中：
因此，我的ViewModel基本上与我的Model相同，只是带有所有与视图绑定的OnPropertyChanged功能。
随着我的重构和扩展，似乎每次对模型进行小改动时，我都必须对ViewModel进行镜像更改。
这似乎违反了设计模式的一个基本原则：不要重复自己。
我是否错误地实现了MVVM模式，或者MVVM中始终存在Model和ViewModel之间的一对一重复是固有特性？
我个人认为这并不违反DRY原则，因为模型和视图模型（我更喜欢称之为Presenter）并不指向相同的信息。例如，您的VM和M都具有Title属性，但是您的VM的Title属性可能还包括验证，而模型的Title属性可能会假定其有效性。
虽然VM可能包含模型的所有属性，但也有可能具有验证（例如：Title必须非空），数据依赖项，可绑定的UI特定属性（图标、颜色、画刷等），这些都不是视图的一部分。
实际上，所有UI模式在你所述的方式中都有类似的“重复”：即级联修改。试着在不改变控制器的情况下更改MVC中的模型。
话虽如此，MVVM（或任何旨在将UI、逻辑和状态分离的UI模式）可能对像你的例子这样简单的情况过于繁琐。当逻辑仅仅是状态传递时，将控制器/Presenter/视图模型分离的价值就会降低。
在您的特定情况中，如果确实没有逻辑、验证或UI特定属性未在VM公开，并且您的模型不需要持久化、序列化或与现有结构兼容（或在VM中添加此逻辑很简单），我强烈建议将M和VM合并，以避免创建唯一目的是获取/设置基础模型属性的属性。
public abstract class ViewModelBase<T>
{
public T Model { get; set; }
}
public abstract class SampleViewModel
{
public int MyProperty
{
get { return Model.MyProperty; }
set
{
Model.MyProperty = value;
OnPropertyChanged("MyProperty");
}
}
}
// The primary Model classes
public partial class OrderItem {
public int Id { get; }
public int Quantity { get; set; }
public Product Item { get; set; }
public int Total { get; set; }
public void ApplyDiscount(Coupon coupon) {
// implementation here
}
}
public partial class Product {
public int Id { get; }
public string Name { get; set; }
public string Description { get; set; }
public decimal Price { get; set; }
}
// The shared views of those model classes
public partial class OrderItem : IOrderItemDTO {
public IProductDTO Item {
get {
return this.product;
}
}
}
public partial class Product : IProductDTO {
}
// Separate interfaces...
// You enforce the rules about how the model can be
// used in the View-ViewModel, without having to rewrite
// all the setters and getters.
public interface IOrderItemDTO {
int Id { get; }
int Quantity { get; set; }
IProductDTO Item { get; }
int Total { get; }
}
public interface IProductDTO {
string Name { get; }
string Description { get; }
decimal Price { get; }
}
// The viewmodel...
public class OrderItemViewModel {
IOrderItemDTO Model { get; set; }
}
这里似乎有一件被忽略的事情，而你的简单例子没有暴露出来，那就是你的视图经常会聚合多个域模型类型中包含的数据。在这种情况下，你的 ViewModel 将包含对多个域模型（类型不同）的引用，从而聚合了一组相关数据，可能是某个特定视图希望公开的。
其他人已经对MVC/MVVM模式的组件角色提供了很好的评论。我想提供一个基本观察，解释不管选择哪种模式都会出现重复性。
通常情况下，数据层、业务层和UI层之间会存在某种形式的重复。毕竟，一般需要将每个属性展示给最终用户(UI)、对其行为进行建模(业务层)，并保持其值(数据层)。
正如其他人指出的那样，每个层次上可能会略微不同地处理属性，这解释了某些重复性的根本原因。
在处理足够大的系统（或者与正确团队一起进行的小型项目）时，我倾向于使用UML对这种类型的信息进行建模，并使用代码生成（通常与部分类配合使用）来处理重复的方面。举个简单的例子，姓氏属性可能有一个要求（在我的UML模型中），即将数据限制为50个字符。我可以生成代码来强制执行该限制到我的UI层（例如通过物理限制输入），生成代码到我的业务层以重新检查该限制（“不要相信UI”），例如如果数据过长，则抛出异常，并生成我的持久层（例如NVARCHAR（50）列，适当的ORM映射文件等）。 2012年更新微软的数据注释及其在UI层（例如ASP.Net MVC）和数据层（Entity Framework）中的支持，大大有助于实现我之前为许多问题生成代码的工作。
这是一个有趣的评论...确实，经常需要修改ViewModel以反映Model中的更改。
如果可以自动化就好了...实际上我认为这是可能的，通过在ViewModel中实现ICustomTypeDescriptor：通过反射获取GetProperties将返回模型的所有属性。但是我不确定它是否有意义，因为模型可能根本不包含属性：它可以是方法、字段或任何东西，并且并非模型中的所有内容都对ViewModel有用。
我只知道MVC，而在MVC中，包含GUI的Model-Class存在一些错误。SmartForm似乎是一个表单，这意味着它不是一个模型。我不知道你试图编写什么程序，但我给你举个例子：
以日历为例。您可以询问该类今天是什么日期，是哪个月，每个月有多少天等等。但它没有图形表示。视图（CalenderViewMonth或其他您想要的）在屏幕上打印一个月份。它知道一个日历并询问它在不同单元格中要写什么。
本质上，您可能在建模/理解MVVM方面有一些问题（这是MVC的现代.NET变体）。
编辑：
我刚在维基百科上查了MVVM。Model就像MVC中的Model一样。View也像MVC中的View一样——只是图形表示。ViewModel是通用视图和专业模型之间的粘合剂。某种适配器。不应该违反DRY原则。