I need some help to architect an MVVM application. This time I want to do it in the right way.
My View is bound to the ViewModel which is bound to the Model. No problem there. Displaying data is not the problem, updating it is my problem.
So when the View asks the ViewModel to update the Model (with a Command), which need to handle the logic?
In my case updating the data is not trivial, there are many calculations with many files.
Also, I really want that the Model does not know the business logic. So how to do this? A property in the Model which indicates that the he wants to be updated? Or maybe the ViewModel have to know the business logic? Is it the Best practice?
The model is really a snapshot of the state of your business data. Your non-trivial calculations can be encapsulated in services that can be abstracted behind interfaces and injected into your view model. This way your view model knows nothing of these complex processes other than calling them via interface contracts. So your command fires and your view model provides orchestration, your service provides actual business calculations and an updated model would be produced representing the new state of the system.
Related
I'm trying to get up to speed with using WPF and the Prism framework which is heavily associated with the MVVM pattern. I've ready many different descriptions, examples and discussions on MVVM and each one is slightly different and has left me a little confused.
My understand is as follows:
The MVVM pattern has 3 parts to it :-
Model - the classes that hold the application data/information.
View - The visual elements of the application.
ViewModel - The logic, state and other behaviour associated with the visual elements. It takes data from the model and exposes it (possibly with some data conversion/formatting) in such a way that the View can use it directly.
What I'm not sure about is:
Do these 3 parts cover every part of the application? Or can there be parts of the application that are outside these 3 parts?
Is it the ViewModel or some other part that is responsible for populating the Model?
Thanks in advance
Absolutely not. Unless they do. If your application is simple, then everything can be handled in the View, ViewModel or Model(s). If your application is complex, and best practices dictate you break out logic into their own types (communication logic, repository logic, etc), then there is no stopping you. MVVM is only concerned with view-centric logic within the View, application logic within the ViewModel, and the means of storing information for transmission between the two.
The ViewModel is solely tasked with interpreting user actions and readying the results of logic within Models so that the View may display this information to the user. In some cases, it makes sense that a Model itself hold some logic so that it may respond to user actions. However, it has been my experience that this mini-ViewModel-Model design is in reaction to design decisions by inexperienced developers. Once you get the real hang of MVVM, you usually don't have to (or want to) put any code in your Models apart from validation logic.
Think of Model, ViewModel and View as logical layers that handle Business, application flow and presentation respectively. For example, a ViewModel class may delegate complex or reusable UI interactions to a separate service that doesn't correspond to any particular view but still belongs to ViewModel layer.
Yes, ViewModel stands between UI and Model.
The question is stated in the subject: are the advantages of Model-View-ViewModel (MVVM) pattern worth the overhead?
In many cases, implementing the view model involves quite significant overhead of duplicating the Model properties and sometimes synchronization between Model and ViewModel data members. For example, currently in Silverlight 4 & WCF RIA, View Models are not generated (if the developer follows the MVVM pattern, it is up to him to create the view models, often duplicating the corresponding Model's properties at ViewModel, that do nothing significant but refer to Model as the storage).
Why not extending the Model class, providing additional properties to make it easy to be consumed by the View instead?
Why not extending the Model class, providing additional properties to make it easy to be consumed by the View instead?
Effectively that is what the PresentationModel is for. Which MVVM is strongly based on. The difference is that the ViewModel is the model for the view and not the model for the data. So you are concerned around more how the view behaves with the data.
If you have a simple UI that all it does is present the model then I would suggest expose the Model on a property of the ViewModel and bind to that. Make sure though the model does implement INotifyPropertyChanged etc.
The power of the ViewModel is when you have things to do in response to a user action. The ViewModel can then support Commands, calling out to services and validation and thus leaving the Model as a data container
Why not extending the Model class, providing additional properties to make it easy to be consumed by the View instead?
In the simple cases, this is all the ViewModel is doing - wrapping up the Model so that its extended in a way that's consumable by the View. If your Model can be bound directly, you're welcome to do so.
That being said, there is more to the ViewModel layer than just wrapping the model - this is also where the application specific logic - ie: the application's plumbing, will occur. Something has to make the requests from the Model classes correctly and compose together the logic.
If you are concerned about extra work, you can always create a ViewModelBase (INotifyPropertyChanged , Errors/Validation, generic stuff) to be inherited by your ViewModel, it will minimize things that you think may cost you time to replicate. And also, Silverlight/Wpf provides us with binding which greatly reduces our coding, besides the fact that XAML also does that by providing functionalities through markup. Besides that you can further the design by using screens, controllers, etc.
For me, I do not see any "overhead" with regards to using MVVM; if there were, it'd be worth it. It properly deals with the Separation of Concerns. It provides a good platform for development especially in teams where people may take care of different aspects of the application without affecting other team members codes (especially between developers and designers).
Hope this helps
Benefits of MVVM
Reduced complexity.
Isolation of Designing and Development.
Dependency injection.
Major advantage is when you have a Well MVVM structured Windows Phone application and want to develop same for Windows Metro Desktop, Only thing u want to concentarte on design as the same view model can be used as it is.
Hope it helps.
I am using a WCF service reference in a WPF project, and my entity framework data model resides in WCF project.
And I am using MVVM Light framework. I am doing the following things:
I use LINQ in the service to get data and then fetch it from WPF, obersvablecollections usually.
Everything works in view part like populating datagrid, views as required.
But I have following doubts:
Is this correct way of transferring data between wcf and wpf.
I haven't used the Model for anything yet, I have doubt about when to use it?
I also wanted to save data from datagrid. I was able to pass on the observablecollection of updated data of datagrid to the service's function. But how do i update the entity from this collection? by looping? doesnt sound right. Once I update the entity from this collection I will be able to use saveChanges to update into database.
When I need to show hierarchal data in a treeview, where to make that data hierarichal, from stored procedure xml? use a view to create a grouping criteria column? create this column in service? create this column/property in presentation?
1 - There is no correct way, it depends on your requirements and goals.
2 - With MVVM, the model should sit between WPF and the database. That means all calls to the database should go through the model, and all writes to the database should also go through the model. The WPF GUI should only bind to the model. This usually means that your WPF portion consists mostly of XAML code. All code that accesses the database should be in the model.
There are good reasons for separating this.
You can write unit tests that on the model.
The view model is independent from the look of the GUI. This means that you can easily change the GUI by dropping in different components and just binding to the model.
A quick google search can probably yield more reasons.
3 - I would try to send over only the entities that have changed. This can be done by passing the collection to your view model, and have your view model figure out what has changed.
4 - I don't quite understand what you want to do. Usually, to make a TreeView, you should create HierarchicalDataTemplate for each of your view models. The TreeView control will take care of the rest. You should really do some tutorials on this one, because it's kinda hard to wrap your head around.
I'm studying WCF and WPF. I've learned a lot by doing sample projects, but I'm having trouble putting everything together. It would help if I could paraphrase my understanding of proper WCF/WPF structure and invite others to confirm or correct my ideas. Here is a very broad description of how I expect my next project to work:
My persistent data will be stored in a SQL Server database. I will create a WCF Service Library which serves as an interface to the database, solving security issues and recasting the relational data into an object-oriented entity model. My application will read data through the WCF service into a memory structure which might be customized somewhat for the needs of my application, but will basically consist of one ObservableCollection for each of the entities in my data model. Because the data will be stored in ObservableCollections, I will be able to use event procedures to respond to data changes that trigger business processes. Simple user interface elements will bind directly to the collections. More sophisticated user interface elements, like a TreeView, will require another layer, called a PresentationModel or ViewModel. In the case of a TreeView, the TreeView will bind directly to the PresentationModel, and the PresentationModel will bind directly to the collections.
Have I described everything correctly?
-TC
There is nothing technically wrong in what you wrote.
Things that feel off:
... solving security issues...
Scares me because it implies, to me at least, that you will have no security issues. I would have phrased it as
provideds a centralised system for authentication and authorisation to the data from all interfaces
I would definately make use of the MVVM pattern, allow a ViewModel to expose your collections and properties that your UI binds too, you seem to have a grasp of that pattern from what you have described.
Is WCF really required for your data layer? Have you looked into Entity Framework at all?
Simple user interface elements will bind directly to the collections.
I'd advise slightly against the above. A decent model to follow is the MVVM (Model-View-ViewModel) pattern. It sounds like you've read a bit about this considering your ListViews are going to be contained in a ViewModel. I would also have your raw data models exposed to a ViewModel, and have your View bind to that. So, for your raw data models, use them like you intend to do with ListViews.
Other than that, sounds like you're spot on.
i know some Mvvm Frameworks that introduced in this thread
please describe or give me link for that what are them useful for?
not information about MVVM about MVVM Framework.
thanks :)
i want to know :
What Is MVVM Framework?
I think your question is not really precise. As far as I understand, you ask for the features of each framework?!
You can find detailed information here and here. However, at least one of these links has already been given in the thread you mentioned...
EDIT:
Basically, an MVVM framework is a collection of classes which are commonly used in applications utilising the MVVM (Model-View-ViewModel) pattern. This may include messaging systems to communicate between independent parts of a software, dependency injection techniques, base classes for ViewModels, project/class templates, validation mechanisms, commonly used commands, techniques for displaying dialog boxes, and so on...
To completely understand such a framework, you will have to understand the MVVM pattern first. Because only then (or even only after you did your first MVVM project) you will have an understanding of the problems and/or challenges of this pattern.
To use Mvvm framework just simply follow below steps:
You have a model and a view-model with the same name.
View-models are not supposed to be wrappers around models. The job of a view-model is to broker requests for external services such as the loading and saving of data. The data itself, as well as validation and most of the business logic, should be in the models.
I can’t emphasize this enough. Whenever you create a view-model that wraps a model by delegation you introduce a huge hole in your API. Specially, anything with a direct reference to the model can change a property in such a way that the view-model and thus the UI are never notified. Likewise, any changes to calculated fields in the model won’t be propagated back to the view-model.
You have a view and a view-model with the same name.
Ideally view-models are agnostic to the screens they are used by. This is especially true in a WPF application where multiple windows may be sharing the same instance of a view-model.
For smaller applications such you may only need a single view-model for the whole application. For larger applications you may need one for the main functionality and one for each secondary aspect such as configuration management.
You have no code behind.
In absolute terms code behind is neither a good nor a bad thing. It is merely a place to put logic that is specific to a single view or control. So when I see a view with no code-behind at all I immediately check for the following mistakes:
Does the view-model touch specific controls by name?
Is the view-model being given access to controls via a command parameter?
Is EventToCommand or another leaky behavior being used in place of simple event handler?
EventToCommand from MVVM Light is especially bad because it will prevent controls from being garbage collected after they are removed from the screen.
View-models are listening to property changed notifications
If a model has a longer life-span then the view-model that listens to its events then you probably have a memory leak. Unlike views which have an unloaded event, view-models don’t have a good story for life-cycle management. So if they attach an event to a model that may out-last them then the view-model will be leaked.