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.
Related
Is it OK to use my Domain Model as Model in the MVVM pattern, in the context of a WPF application? Or is the Model (in MVVM) supposed to be some POCO? I personally don't see any reason against using the Domain Model as Model of the MVVM WPF pattern.
But then the XAML elements will bind to what? Properties in the VM, which underneath are mapped to the Domain Model, right?
To answer the question posed in your title: neither.
In MVVM, the "model" is generally everything the other side of the viewmodel (i.e. between the viewmodel and the repository). The model can (and usually is) composed of several different additional architectures and patterns, it is normal to have services, micro services, DALs and DILs, domain models, POCOs/data entities etc all within the "model".
The domain objects and POCOs you speak of are not the model, they are part of the model. The perspective of the model that you talk of has been brought over from other patterns like MVC, where a data entity or domain object is indeed the model. The model is a little more complex than that in MVVM.
You can bind directly to a POCO in MVVM, but it's not usually a good idea unless it is a very simple one that is not subject to change (like a lookup list that is sourced from a repository). And it is usually quite a bad idea to bind to domain objects because these will contain extra functionality or information that is related to storage and retrieval but is overkill for anything shown in the UI. The other problem with domain objects is they usually don't serialize nicely (if at all - often domain objects are generated), so unless you have a very simple model it is best to transform the domain objects to POCOs as soon as practical.
So as mentioned in the answer from Owen, you should wrap your POCOs with viewmodel classes before they are made available to the UI. The only time you shouldn't is when you don't need any property change notifications and you also don't want to leverage any further functionality on the objects (for example you won't need a context menu on the displayed item).
But then the XAML elements will bind to what? Properties in the VM, which underneath are mapped to the Domain Model, right?
Yes, you could reference your POCO model entity classes in your WPF application and wrap them in view model classes that implement the INotifyPropertyChanged interface to provide support for dynamic change notifications. This is perfectly fine.
Please refer to my answer to the below question for more information about this.
Correct way to update property in ViewModel from Model
You'll likely want to wrap your domain model objects with view models. The purpose of your view model is to expose data from your model in a way that is useful to the view. For very simple applications it might seem cumbersome to add that extra layer just for change notification, but as your application becomes more complex, having a view model layer to bind to can help keep your model clean. If you are doing something quick and dirty, there is nothing stopping you from binding directly to your domain model objects.
Yes as long as your domain model implements inotifypropertychanged you can use and bind xaml with VM properties
I'd like to create a Silverlight app using WCF Ria Services and the MVVM design pattern.
The main page of the app will consist of a "shell" and a large number (10s or 100s) of objects of different look (shape/size/properties) linked to each other (forming a sort of graph).
These items need to be mouse-draggable and their current position/state needs to be saved to the back-end database.
I feel that the best way to achieve this would be to have a small ViewModel and View for each item displayed, put all the important properties into the ViewModel and then somehow display all these Views in the main "shell".
However, I don't know how exactly this could be achieved. I considered using MVVM Light, but didn't find any example that would show something similar.
Can anybody point me to some examples or ideas about how this could be done?
"When all you have is a hammer, everything looks like a nail" :)
MVVM is not designed to manage graphic intensive situation like the one you describe. It is a glue for stitching together high-level concepts in a flexible manner. With MVVM you are adding overheads that will impact performance (e.g. binding uses reflection behind the scenes). The more objects involved, the greater the impact.
The best starting point I can suggest is to imagine what you need from a 3rd party control (e.g. a custom control/container) and, if one does not actually exist already, build it as if it were a third party custom control.
You will find in practice that custom controls are seldom based on MVVM, for performance reasons if not just because "they often don't need it". They may well expose MVVM compatible properties for the external interface, but not for the low-level internals.
MVVM is a relatively high-level technique. Do not feel you have to implement it on everything.
Following MVVM do the next:
Model - create model object which will be responsible for fetching and persistence coordinates of the shapes on the screen;
View Model - one view model which will initiate fetching and persistance model objects;
View - in your case, it's a place where you do most of your work. Create custom control based on ItemsControl with Canvas panel. Custom control should pass collection of the model objects in ItemsSource, allow to drag and drop containers and call the view model command when user drops container in some place
Have a look at the Telerik controls, specifically radTileView, this seems to have the functionality that your looking for. They also have a persistance framework that should allow you to save the position of the tiles back to you database.
I have a Silverlight application that is loading Entities from a WCF Service via DataBinding.
So I have several views with many textboxes whose textboxes contents are binded to a Entity properties.
I want to use Silverlight validation and I don't want to use the exceptions way (I have some entities with a lot of properties... and I don't want to repeat it every time I use it in a form...).
So I'm triying to use the IDataErrorInfo way, but I'm not sure how should I do it.
I think I should declare a client-side model with equivalent classes to the Service EF Model but implementing the IDataErrorInfo. This solution means duplicate the model code and make any way to translate from service model to client model.
The other solution could be to change the EF Model itself but I don't know if this is correct for the MVVM (this is really near to the view, isn't it).
Maybe there is another magical solution I don't know.
Any suggestions??
The recommended interface is actually INotifyDataErrorInfo
Which gives you a little more control and supports multiple errors. It's also a little bit easier to use in scenarios when you manually want to control when validation happens.
Basically, with this, you could create a validate method on your "client side" objects which goes through their properties, validates each one, and builds up a list of errors. (HasErrors becomes true, you notify ErrorsChanged and then the code that binds to your object does GetErrors.
With this way, you could build a validation engine and have each EF object poll your database for validation rules.
There's also this: http://msdn.microsoft.com/en-us/magazine/ee335695.aspx
If you have the option of annotating your EF classes on the client side instead of simply using the generated ones, you may be able to find an easy solution here.
I know this is slightly off-topic since you're using WCF
but if you were to use RIA Services, then it generates objects from your EF, and you can simply add some attributes to them in the RIA (it comes with comments telling you which attributes to use)
and it's very very simple.
but that advice is relevant only if you were to use RIA.
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 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.