I'm working on a project and learning SL/MVVM as I go. I'm using MVVM light and feel as if I have a decent grasp of things. I understand binding controls to the VM and also sending events/commands to the VM.
A few questions I have:
In an MVVM application how is the Application object accessed from the VM, for calling Application.Install or checking install state? Or do you just stick it in the code behind of a view for that case? I suppose this could be done through MVVM messaging but you'd still register a listener in the code behind.
I'm not sure if this can happen but how would one, from the VM, access a method from a View/Control(s) to do something that can't be accomplished through data binding or commanding/eventing? Is this where Dependency Object/Properties come into play?
The application should provide a service for obtaining the information relevant to the Application singleton; as with any data which could be used throughout the application; yours or the frameworks.
If you are ever needing to access a method on a UIElement/FrameworkElement/Control from the ViewModel that would be the point in looking into a custom Control or UserControl to provide the needed behavior. That is typically solved via Triggers and Behaviors.
Related
I am writing a custom control in WPF, and i have a couple of methods in the control that the user of my control can invoke.
Although it can be invoked directly, due to requests from users, i want to enable the control's methods to be invoked in a MVVM manner.
After research, i take it i have to implement ICommandSource on my control.
The MSDN has an example but i find it too much over-engineered for my situation (or maybe because i don;t understand it at all!).
All i want is to let my consumers to call my method via a command rather than put their calling code in view's code behind.
Please advise with a simple sample code to implement this. Thanks.
In the Blend SDK is a behavior MethodInvoker (if my memory serves correct) that allows you to bind to a method. That way you do not have to implement ICommand.
If you have access to reflect over the .NET code (or you can download the .NET source code via download) look into how MS does it with ButtonBase. Yes, there is a lot of code under the hood, but that's because if you're going to create a custom control you should account for both scenarios of RoutedEvents and Commands.
I understand MVVM's usefulness in the context of a large team developing a shrink-wrapped application over a long period of time. But in the context of an internal LOB application, MVVM seems overkill and I'm having trouble swallowing the overhead of debugging declaritive databindings, jumping from layer to layer to layer, and extracting VM's that are barely more than the Model with a command or two. Even accepting that overhead, still leaves me with the holes in MVVM like dialogs. A few things I've considered is:
Binding directly to the Model and do old-school event handlers for form interaction
Binding a user control or window to itself, effectively using the code behind as the VM.
Include a property in my VM to reference the related view.
Make ViewModel's subclasses of a View.
The above items and their combinations address some problems but not all. I do realize that I might sacrifice testability. What other technical (not conceptual like SOC) issues will I run into using one or more of these practices?
I always use MVVM when coding in WPF or Silverlight, even for small single-page apps. It makes it much easier to test and maintain in the long run, and I find it faster to create apps with it than without it
I don't mind taking some shortcuts in smaller apps, such as binding to the Model instead of exposing the Model's properties in the ViewModel, or defining my View in a DataTemplate instead of a UserControl, or using Window's Dialogs in my ViewModels, but I would never consider doing a WPF or Silverlight app without MVVM.
If you want, I have an example of a very simple app done with MVVM here
Code re-usability comes to mind. Properly written VM's could be re-used behind Silverlight or WP7 implementations down the road.
I have a silverlight bing map application. I am using the MVVM pattern with PRISM.
The bing map has a "BoundingRectangle" property that is not available in XAML, but it is available via code behind. Of course this does me no good since I need the data in my viewmodel which doesn't have access to the View's code behind (nor do I want to add it, since I'd really like to try to not use the view's code behind if possible).
Normally, you would do a two way bind to a viewmodel property. The Bing map will surface BoundingRectangle for layers, but not for the base map (that I can find).
I'm not looking for a hack here, just wondering what the best practices or convention for getting data out of a view to a viewmodel that isn't "bindable".
Thanks!
Databinding in Silverlight is just a framework feature that automatically synchronizes data between your view and your view model (if you are following the MVVM pattern). However, there is nothing wrong with doing this yourself!
The two main advantages of the MVVM pattern (other than the usual separation of concerns that most UI patterns provide) are:
It aids unit testing, the View Model can be exercised from your unit test code without a view present.
It helps the developer / designer workflow, reducing the files shared between the designer and developer.
In my experience, having a small amount of code-behind that 'assists' the binding framework does no hard at all!
You can use techniques such as attached behaviours to wrap this code up, but often this just results in a cosmetic improvement.
CraigF,
you can use Mediator pattern, if you use Galasoft Light toolkit then use messenger to send message from view to your viewmodel. Viewmodel register to that message and if recive one set your property in viewmodel and do some logic..
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.
I don't develop too many desktop / Windows Forms applications, but it had occurred to me that there may be some benefit to using the MVC (Model View Controller) pattern for Windows Forms .NET development.
Has anyone implemented MVC in Windows Forms? If so, do you have any tips on the design?
What I've done in the past is use something similar, Model-View-Presenter.
[NOTE: This article used to be available on the web. To see it now, you'll need to download the CHM, and then view the file properties and click Unblock. Then you can open the CHM and find the article. Thanks a million, Microsoft! sigh]
The form is the view, and I have an IView interface for it. All the processing happens in the presenter, which is just a class. The form creates a new presenter, and passes itself as the presenter's IView. This way for testing you can pass in a fake IView instead, and then send commands to it from the presenter and detect the results.
If I were to use a full-fledged Model-View-Controller, I guess I'd do it this way:
The form is the view. It sends commands to the model, raises events which the controller can subscribe to, and subscribes to events from the model.
The controller is a class that subscribes to the view's events and sends commands to the view and to the model.
The model raises events that the view subscribes to.
This would fit with the classic MVC diagram. The biggest disadvantage is that with events, it can be hard to tell who's subscribing to what. The MVP pattern uses methods instead of events (at least the way I've implemented it). When the form/view raises an event (e.g. someButton.Click), the form simply calls a method on the presenter to run the logic for it. The view and model don't have any direct connection at all; they both have to go through the presenter.
Well, actually Windows Forms implements a "free-style" version of MVC, much like some movies implement some crappy "free-style" interpretation of some classic books (Romeo & Juliet come to mind).
I'm not saying Windows Forms' implementation is bad, it's just... different.
If you use Windows Forms and proper OOP techniques, and maybe an ORM like EntitySpaces for your database access, then you could say that:
The ORM/OOP infrastructure is the Model
The Forms are the Views
The event handlers are the Controller
Although having both View and Controller represented by the same object make separating code from representation way more difficult (there's no easy way to plug-in a "GTK+ view" in a class derived from Microsoft.Windows.Forms.Form).
What you can do, if you are careful enough. Is keep your form code completely separate from your controller/model code by only writing GUI related stuff in the event handlers, and all other business logic in a separate class. In that case, if you ever wanted to use GTK+ to write another View layer, you would only need to rewrite the GUI code.
Windows Forms isn't designed from the ground up to use MVC. You have two options.
First, you can roll your own implementation of MVC.
Second, you can use an MVC framework designed for Windows Forms.
The first is simple to start doing, but the further in you get, the more complex it is. I'd suggest looking for a good, preexisting and well-tested, MVC framework designed to work with Windows Forms. I believe this blog post is a decent starting point.
For anybody starting out, I'd suggest skipping Windows Forms and developing against WPF, if you have the option. It's a much better framework for creating the UI. There are many MVC frameworks being developed for WPF, including this one and that one.
According to Microsoft, the UIP Application Block mentioned by #jasonbunting is "archived." Instead, look at the Smart Client Application Block or the even newer Smart Client Software Factory, which supports both WinForms and WPF SmartParts.
Check into the User Interface Process (UIP) Application Block. I don't know much about it but looked at it a few years ago. There may be newer versions, check around.
"The UIP Application Block is based on the model-view-controller (MVC) pattern."
Take a look at the MS Patterns and Practices Smart Client application block which has some guidance and classes which walk you through implementing a model view presenter patter in windows forms - take a look at the reference application included.
For WPF this is being superseced by the prism project
The software factories approach is a great way to learn best practices