我正在编写一个 WPF 桌面应用程序。我正在尝试了解 MVVM 数据流。我使用实体框架作为数据访问，并且我使用代码优先的方法，所以我有代表每个 SQL 表的 POCO 实体类。
通过这种配置，我的理解是我的模型（MVVM 中的 M）是我的 POCO 实体类。我的视图（MVVM 中的 V）是我的 WPF 窗口。
什么填充了我的视图模型？我是否只是在我的视图中进行 EF 查询，填充视图模型？我的视图模型是否执行自己的查询（可能在类构造函数中）？
【问题讨论】：
标签： c# wpf entity-framework mvvm
通常，视图是一个 WPF 窗口，它背后有相应的代码。视图模型是一个简单的类，创建它是为了处理特定视图的数据层要求并进行处理。通常在控件的 XAML 视图中使用命令，并且每个命令都绑定到视图模型中的命令实例。视图模型可以通过依赖注入创建，也可以在后面的视图代码中传递给构造函数，并作为成员/属性存储在后面的代码中。确保将视图数据上下文设置为视图模型的实例，以便允许绑定到视图模型中的属性和命令。
this.DataContext = new TheViewModelType();
实体框架普通的旧 CLR 对象是数据模型，视图通常不应该知道这些。视图模型可能具有视图可以绑定到的模型类型的属性，例如项目控件等。所以在视图中：
<ItemsControl x:Name="CarItems" ItemsSource="{Binding Vm.CarsCollection}"></ItemsControl>
因此，由于视图的 DataContext 是视图模型类型的实例，因此视图控件可以直接绑定到视图模型中的属性。该示例是具有 Cars 集合的视图模型，并且视图模型可以在需要填充 Cars 集合时调用服务。显然，a Car 是模型。
public MyViewModel( )
{
Cars = TheCarsDataLayerService.GetCars( );
}
private IObservable<Car> _cars;
public IObservable<Car> Cars
{
get { return _cars; }
set
{
if( _cars == value )
return;
_cars = value;
RasisePropertyChanged("Cars");
}
}
对于示例中的 Cars 服务，这可能是数据层存储库，也可能是实体框架 DbContext 的实例。因此，视图模型可以具有 DbContext 派生类型的字段或此类服务，并且可以将其传递到视图模型类的构造函数或注入依赖注入，或者该服务可能是视图模型的静态工厂或单例只需调用 in 以使用视图将向用户显示的数据填充其成员。
MVVM 是一种非常基本的设计模式，可以通过多种不同的方式实现。一些开发人员会将模式提升到新的高度，并严格遵守模式组件通信的许多规则。最终，无论它是如何实现的，使用该模式总比不使用任何模式要好得多，因为它可以让代码更好地扩展，其他开发人员可能更容易理解代码并期待某些事情。此外，MVVM 模式允许 WPF 开发人员进行单元测试。如果做得足够好，可以测试视图模型，并且由于视图代码中没有代码，并且视图除了显示它甚至不知道的数据之外什么也不做，测试视图模型就足够了。
【讨论】：
严格使用您的域模型作为视图模型，即使不是立即也会给您带来问题。通常，域模型由原始数据组成，它可能包含也可能不包含业务操作，例如，有些可能会将其放在 BusinessLayer 管理器类中。但是你的VM ViewModel 是严格针对视图的，应该只存在于视图项目中。使用与视图相关的下拉列表等使您的域杂乱无章...不是放置这些“视图”数据源的合适位置。
因此，用代码术语来说，您的视图模型可以包含一个引用域模型实例的属性，或者您可以添加视图将公开的每个属性。但是通过分离 ViewModel 和模型（域模型），您允许视图能够公开/隐藏它需要的内容以及转换某些属性，例如 EntityFramework 模型可能包含字符串属性，但您的视图可能需要严格它在一个屏幕上的数字表示，而另一个可能允许作为字符串属性进行编辑，重点是您的 EF 模型（域模型）不需要担心这些视图问题。
你在哪里创建虚拟机？
控制器的工作是解释请求并确定所需的视图和视图模型。因此，将在控制器中使用 EF 域模型类（以编辑请求为例）作为 VM 的源来创建 VM。
【讨论】：