为应用程序实现 MVVM 模式时出现的问题
首先告诉你我对 WPF 很陌生，
我有一些问题，我在网上没有找到答案......有些教程在那里，但它们再次令人困惑...... ..
问题：
1) 可以将 MVVM 用于有时限的项目（提前交付）。
2）我应该如何制作我的对象模型（实体类）。
3）数据访问层在哪里。在模型中??...
4）业务逻辑（某些部分）是否位于VIEW MODEL
5）最令人困惑的-----我必须制作多少个VIEW MODELS......我在网上看到了一些示例应用程序......它们要么在1内完成视图模型或者他们使用比实体类多 1-2 个视图模型......
我应该使用一个框架来实现初学者级别......请给我推荐一些......
不只是我，很多同事也面临着同样的问题......
First to tell you i am really new to WPF
I have some Question for which i have not found ne answers on the web ..... Some Tutorials are there but again they are just confusing.....
Questions :
1) Can MVVM Used fro Time Bound Projects (Early Delivery).
2)How should i make my Object Model (Entity Classes).
3) Where will be the data access layer. In the Model??...
4) Is the business logic (Some Part) is in VIEW MODEL
5)Most Confusing of all----- How many VIEW MODELS Do i have to make.....I have seen some sample application On the web ....Either they Finish in 1 View Model or they use 1-2 more VIEW Models than there Entity Classes....
Should i use a framework for implementing for the beginner level...please suggest me some....
Not just me but many of my colleagues are also faceing same issues...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我理解 MVVM 的方式是这样的：
1）你的 UI 数据绑定到你的 ViewModel。您的 ViewModel 反过来包装您的模型，并将其转换为绑定友好的界面。模型可能是持久性友好的，但持久性友好的模型并不总是 UI 友好的。 ViewModel 的想法是弥合这一差距并使模型适应 UI 可以轻松绑定的内容。
2）如果您愿意，您的模型可以是任何类实体框架，也可以是普通类（我的偏好）。唯一重要的是它能够在属性更改时通知您的 ViewModel。所以我通常建议模型类实现 INotifyPropertyChanged 或类似的东西。
3）这是一个设计决定，由您决定。您的数据访问层应该与模型分开，但应该与模型交互。请参阅单一职责原则。您的模型仅存储数据。
4) 业务逻辑可以位于 ViewModel 中，是的，也可以位于协调一个或多个 ViewModel 的控制器中。
5) 您通常希望为每种类型的 UI 元素创建一个 ViewModel。这可以变得非常细粒度，特别是当 ViewModel 包含其他 ViewModel 时。例如，如果您的 UI 中有一个网格，则可能有一个用于整个网格的 ViewModel，然后有另一个用于行本身的 ViewModel 类。 ViewModel 多于 Model 的情况并不罕见 - 例如，您可能有一个用于网格行的 ViewModel，以及一个用于详细信息视图的不同 ViewModel，但它们可能映射到同一个 Model。
希望这有帮助！
The way that I understand MVVM is this:
1) Your UI is data-bound to your ViewModel. Your ViewModel in turn wraps your model, and converts it into a binding-friendly interface. Models might be persistence friendly, but persistence friendly models are not always UI friendly. The idea of the ViewModel is to bridge that gap and adapt the Model to something the UI can easily bind to.
2) Your model can be any class- entity framework if you prefer, or plain classes (my preference). The only important thing is that it be able to notify your ViewModel when it's properties change. So I usually recommend that the model class either implement INotifyPropertyChanged or something similar.
3) This is a design decision, up to you. Your data access layer should be separate from the Model, but should interact with the Model. See Single Responsibility Principle. Your Model only stores data.
4) Business logic can be in the ViewModel, yes, or in controllers that coordinate one or more ViewModels.
5) You typically want to create one ViewModel per type of UI element. This can get pretty fine-grained, especially when ViewModels contain other ViewModels. For instance, if you have a grid in your UI, you might have a ViewModel for the whole grid and then another ViewModel class for the rows themselves. It isn't unusual to have more ViewModels than Models- for instance, you might have a ViewModel for a grid row, and a different ViewModel for a Details view, but they might map to the same Model.
Hope this helps!