MVVM，我应该将逻辑放在模型还是视图模型（控制器）中
我是 MVVM 的新手，现在在 silverlight 项目上做一些 MVVM 重构工作，假设它是一个图书购物应用程序。
View是一个书籍列表，我将书籍的标题绑定到ViewModel。所以我有一个 public string Title { get;放; ViewModel 中的 } 也是一个 public string Title { get;放; ？
现在我想放置一个事件处理程序来更新书名，我应该将事件处理程序放在 ViewModel 还是 Model 中 该模型的用途是什么？
I am new to MVVM and now doing some MVVM refactorying work on a silverlight project, suppose it is a book shopping application.
The View is a book list, I bind the title of the books to the ViewModel. So I have a public string Title { get; set; } in ViewModel, also a public string Title { get; set; } in Model (am I right?)
Now I want put a event handler to update the book title, should I put the event handler in ViewModel or Model? and what is the Model used for?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我看来“都不是”...将控制器类添加到 MVVM 的组合中。
将控制器代码放入视图模型中的问题在于，这使得它们更难以独立测试。从很多方面来说，我认为这和隐藏代码一样糟糕。
在我看来，每个人都认为 MVVM 没有控制器，因为他们忽略了 C。MVVM 实际上是 MVC 的变体，“只是添加了 ViewModel”。
也许它应该被称为 MVCVM？
ViewModel 的作用只是从视图中卸载“GUI”代码并包含用于绑定的任何数据。 ViewModel 不应进行任何处理。一个好的测试是您的 ViewModel 可以通过自动化单元测试进行测试，并且不依赖于数据源等。他们应该不知道数据实际来自哪里（或者谁在显示数据）。
虽然它可以被忽略/避免，但控制器应该负责决定显示什么数据模型以及在哪些视图中显示。 ViewModel 是模型（MVVM 中的 M）和视图之间的桥梁。这允许更简单的“分离”XAML 创作。
我们在最近的所有项目中成功使用的模式是仅在模块中注册控制器，并在启动时初始化它们。控制器非常轻/薄，并且是应用程序生命周期中唯一需要悬挂的东西，用于侦听或发送消息。然后，在他们的初始化方法中，他们注册他们需要拥有的任何东西（视图和视图模型等）。这种轻量级的内存中纯逻辑模式也使得应用程序更精简（例如，对于 WP7 更好）。
我们遵循的基本规则是：
事件
它从哪里来
最后两点是你永远不应该打破的，否则关注点分离就会被抛到九霄云外。
In my opinion "Neither"... Add controller classes to the mix of MVVM instead.
The problem with putting controller code in view models is that is makes them harder to test independantly. In many ways I see this as just as bad as code behind.
It seems to me that everyone assumes MVVM has no controllers as they left out the C. MVVM is really a variation of MVC "that just adds ViewModels".
Maybe it should have been called MVCVM instead?
ViewModels are only there to offload the "GUI" code from the view and to contain any data for binding. ViewModels should not do any processing. A good test is that your ViewModel is testable via automated unit tests and has no dependencies on data sources etc. They should have no idea where the data is actually coming from (or who is displaying it).
Although it can be overlooked/avoided, a Controller should be responsible for deciding what data model to display and in which views. The ViewModel is a bridge between Models (the M in MVVM) and Views. This allows simpler "separated" XAML authoring.
The pattern we are using successfully on all recent projects is to register controllers only, in modules, and initialise them at startup. The controllers are very light/slim and the only thing that needs to hang around for the life of the app listening for, or sending, messages. In their initialise methods they then register anything they need to own (views and viewmodels etc). This lightweight logic-only-in-memory pattern makes for slimmer apps too (e.g. better for WP7).
The basic rules we follow are:
events
where it comes from
The last two points are the ones you should never break or separation of concerns goes out the window.
简而言之，模型是“真正的”底层数据模型 - 包含应用程序可能需要的书单的所有信息，能够从数据库获取和设置数据。
ViewModel 是一个主要为视图提供数据绑定的对象。它可能是模型的子集，也可能将多个模型的属性组合到单个对象中。它应该包含必要且足够的属性，以允许视图完成其工作。
如果事件处理程序与 View 相关，则它属于 ViewModel。您可以尝试使用命令模式（请参阅自定义 WPF 命令模式示例 ）如果它符合您的目的。
In simplest terms, the Model is the 'real' underlying data model - containing all the info for the booklist that might be needed by the application, able to get and set data from your database.
The ViewModel is an object that exists primarily to provide data binding for your View. It might be a subset of the Model, or it might combine properties from multiple Models into a single object. It should contain the necessary and sufficient properties to allow the View to do its job.
If the event handler relates to the View, then it belongs in the ViewModel. You might try using the Command Pattern (see Custom WPF command pattern example) if it fits your purpose.