We Keep Coding

ViewModel into View

Currently I'm learning C# with WPF. My mainapproach is to use the MVVM pattern the best I can but now I'm a bit confused.
In my Application for all my views I have a viewmodel:
private DruckviewViewModel ViewModel { get; set; }
public Druckview()
{
ViewModel = new DruckviewViewModel();
DataContext = ViewModel;
InitializeComponent();
}
Is this the suggested way to implement the ViewModel into the View or are there better ways to do it?

MVVM doesn't mean no code-behind.
MVVM is the pattern of separation of concerns. It helps to separate your application's architecture to the three parts(in order of appearance):
Model
View
ViewModel
Where Model is class containing your business logic.
View represents your view class which contains only view related logic(XAML and code-behind) It is Ok to have code-behind unless code contains only view's logic (for example in button click eventhandler you copy color of one textbox to another, which of course can be done in XAML, but from MVVM point of view it is not important)
ViewModel represents View's behavior without any reference to the View.
Notice that for example this property on my opinion will violate MVVM pattern, because Visibility is view related type
public Visibility MyVisibility { get; set; }
So dependencies between parts of MVVM goes like this:
Model doesn't know about anything
ViewModel know only about Model
View know about ViewModel
View ---> ViewModel ---> Model
I think for using MVVM is not important how tightly View bounded to the ViewModel. It is already bounded, because you use ViewModel's properties and commands.
Not bounding tightly (for example using interface as ViewModel) will give your possibility to test View without real ViewModel by creating own "design-time" viewmodels for example.
If your current solution works and satisfy your needs and you just starting with MVVM and WPF then continue with that until you meet need to fully isolate View from ViewModel's types

This will work, but it isn't really true to the MVVM pattern, as the View is now directly tied to the View Model.
Most existing MVVM frameworks use the concept of a View Manager. A class that creates a view from a view model instance, connects them together, and displays the view. You would end up with something like this:
DruckviewViewModel vm = new DruckviewViewModel()
ViewManager.Instance.DisplayViewFor(vm);
It would figure out, based on naming conventions, that DruckviewViewModel uses the Druckview. It would create the view, set the DataContextProperty, and make the view visible.
Without using one of these frameworks, this is a lot of work to build on your own, but this is considered a "Best Practice" pattern.
You may want to consider using an existing framework, a good list comparing their features can be found here.
BTW, if you are wondering how to get intellisense in the XAML designer without setting the DataContext in the constructor of the view. The proper way to do it is to add a design instance in XAML, with an attribute like this.
d:DataContext="{d:DesignInstance local:DruckviewViewModel}"

MVVM in WPF how to communicate with the viewmodel

I guess I am still a little hazy on how communication goes in MVVM. I read that you are not supposed to use events to communicate with the viewmodel, so i assume that you send a command.
However, commands actually bubble up within the visual tree (the view), right? so then it may reach some target control that can handle the command. Does that target control then have a viewmodel that can modify the model?
Sorry, I'm really confused about how to get commands from the view to the model. I assume that getting information the other way is just a simple matter of having the model implement Inotifypropertychanged to tell the viewmodel that it has changed and then have the viewmodel implement inotifypropertychanged so that the view can bind to the viewmodel and have the properties update.
http://blogs.msdn.com/blogfiles/erwinvandervalk/WindowsLiveWriter/ImplementingtheModelViewViewModelpattern_D996/image_14.png

Not all commands bubble - those are RoutedUICommands, which are just a particular implementation of the ICommand interface provided by the framework. You can implement your own ICommand objects that have custom behavior and act just like normal objects (no bubbling, tunneling). If you create them in your ViewModel, certain View objects like Buttons and MenuItems can bind directly to them through their 'Command' properties.

How to set viewmodel property from code-behind using Viewmodel-first?

In my WPF (4.0) application I'm using Viewmodel-first pattern. Hence, my viewmodels are created first, then the views - using data templates. A working demo can be found here.
Now, from within the created views (code-behind), I need to modify a property of the viewmodel. In a View-first approach, I would simply access a named viewmodel instance. However, the Viewmodel-first approach does not allow for this. There is a viewmodel, but the view does not care what it is.
BAD:
Sure you can get hold of the DataContext and use it, but that effectively couples the view and t
the viewmodel.
private void MyView_Loaded(object sender, RoutedEventArgs e)
{
this.viewModel = DataContext as MyViewModel;
}
There has to be a recommended pattern for this. Commands? Messages? Please help!
Q: How do I modify (set a property) the active viewmodel?

Use Bindings to pass data from View to ViewModel and commands to active the ViewModel.
Commands should use a binding to a execute a Command on the ViewModel.
Messages should be used to communicate between ViewModels.
.

You can't do that. Otherwise View will be aware about View Model.
If this initialization is common across all view models, then you can define the properties/events in ViewModelBase and derive all view models from this class.
Q: How do I modify (set a property) the active viewmodel?
You need to use EventAggregator pattern for View-ViewModel communication.
You can use your favorite MVVM framework, and nearly all framework support EventAggregator (or MessageBus or Enterprise Bus).

Should ViewModel have pass-through DependencyProperties that bind to DependencyProperties on the Model?

I am new to WPF/MVVM and the examples I have found do not seem to cover an issue I am facing.
I have a screen for managing a rather complex business configuration object. In MVVM I think this means I should have the following:
A XAML View with close to zero logic
A ViewModel class that has the screen logic
My usual business classes fill the role of Model and have all business logic
In my situation there are business rules that say changes to fieldA of my business class might have various side effects, for example changing the value of fieldB, or populating an entire list of sub-objects.
I could be wrong, but I think I should keep these rules encapsulated in the business class, as these rules are not really about the screen so much as the entity.
Naturally, these side-effects need to make their way back onto the screen immediately.
So from the user's perspective, he might edit fieldA, and see fieldB updated on the View.
I understand how to databind from the View to the ViewModel.
But in my case, it seems that I need two layers of databinding: one between the View and ViewModel, and another between the ViewModel and the Model.
Given that I have essentially the same problem twice, I think one solution should apply. So I have made my Model class into a DependencyObject, and I have made its properties into DependencyProperties.
Looking at fieldA for example, it would appear in all three layers:
View as a visual component databound to ViewModel.FieldA, for example text="{Binding FieldA, Mode=TwoWay}"
ViewModel as a DependencyProperty bound "upward" to the View, and "downward" to the Model
Model as a DependencyProperty
I prefer not to directly couple my View XAML to the business object by skipping part #2, this does not seem like a clean application of the pattern to me. Perhaps that is misguided.
I essentially seem to need a "pass-through DependencyProperty" in my ViewModel.
My questions:
Is this the right general approach or am I thinking about it all wrong?
Are there examples out there using this pass-through approach?
Can someone give a code example of the proper way to create a pass-through binding between the ViewModel and Model FieldA DependencyProperties?

I struggled with this issue myself, and I imagine it is a very common snag when it comes to MVVM. My answer was to avoid polluting the domain with DependencyObject or INotifyPropertyChanged as it somewhat negates the validity of using a ViewModel.
The goal of a ViewModel is to expose a model in a manner that is relevant to a particular view. It gets confusing when the VM essentially needs to expose an entire domain object. I refer to these as "Editor" view models. These are the most tempting to pass through properties from the domain object. In these cases I give the VM a reference to a domain object (composition) and pass through getters and setters. The ViewModel adopts INotifyPropertyChanged and IDataErrorInfo rather than DependencyProperty to signal the UI if the UI needs to refresh or display validation errors. If the domain raises a validation error, then the VM catches it and prepares it into the data error info details for the view.

I would agree with Steve that you should avoid using DependencyObject and DependencyProperty in your model/domain classes, and the view model classes should adopt INotifyPropertyChanged and IDataErrorInfo for binding purposes.
I would add that in your view model classes, I would avoid using DependencyProperty except for properties that you need to utilize in xaml logic, such as DataTriggers.
For handling changes that are triggered within a model layer class, I would also have a reference to the model/domain object in the view model class, and pass through getters and setters to the model/domain class just as Steve mentioned. I would add that the model/domain class will need to raise an event that the view model class will need to subscribe to, so that OnPropertyChanged() for one or more properties can be called in your view model class based on a change that happened in your business logic.

Firstly, I would not recommend using dependency properties (DP) for view models, or models. DPs are properties that have been designed with UI concepts in mind, such as precedence rules, DataContext support, default values and more. You do not need these concepts within a view models, so you should use INotifyPropertyChanged instead.
Having a view-model that is simply a pass-through to a model layer adds no value at all. So don't do it! You should never add layers, structures or concepts to your code just because you think you should. Simplicity is something that you should always strive for.
So, if you can implement a model layer, with INotifyPropertyChanged simply bind that to your view.
However ... in some cases you may not be able to implement INotifyPropertyChanged in your model. It might be generated from a web service for example. In this case you will need a view model that performs pass-through functionality, but also adds change notification via INotifyPropertyChanged.

How should the Model let the ViewModel know about changes in its state?

I am building and MVVM application where some of my Models contain the state of realworld-object that their are modelling. The state changes from outside events, e.g. my Model gets information over TCP/IP about a stock that changes, and updates its state to reflect that change.
Now I would like the change to propagate to my View, and the way to do that, is to let my ViewModel know about the change.
I can think of two ways of doing this.
One, I let the Model implement INotifyPropertyChanged, and fire the event when the property changes. However, this seems to be frowned upon for some reason.
Two, I implement an event for each property that can change in the Model, events that the ViewModel explicitly can bind to.
What is the preferred way? Are there other ways (better ways) of doing it?
Edit:
I have now read, both in the comment from slugster and here, that having the Model have a state is not the purpose of the model.
However, in John Gossmans original MVVM post, we find: "The Model is defined as in MVC; it is the data or business logic, completely UI independent, that stores the state and does the processing of the problem domain."

Option 2 is viable, albeit dirty. You can mitigate the dirtiness somewhat by exposing the public events and functions via an interface, and the viewmodel uses the model only via that interface.
Having said that, the model should be treated as a conduit of information, rather than a container for information. This means that ideally your model should not contain any state information. If you have a persistently open channel in your model that needs to notify other components when something is received then I suggest you use the EventAggregator in Prism - this is a weak event pub/sub system, your viewmodel can subscribe to an event of your choosing, and your model can publish that event when it needs to (along with an appropriate payload).

The model classes typically provide property and collection change
notification events through the INotifyPropertyChanged and
INotifyCollectionChanged interfaces. This allows them to be easily
data bound in the view. Model classes that represent collections of
objects typically derive from the ObservableCollection class.
MSDN
I wouldn't say that a Model typically implements INotifyPropertyChanged, but I wouldn't categorically refuse to do so. In simpler - non-PRISM - environments it's totally fine in my opinion.
And then?
To clarify: INotifyPropertyChanged is an interface for the notification in case of a property change, as the name says and most people know. However, it is not more than this, especially it is not WPF specific! Furthermore, as according to the the MVVM principles, the Model should be agnostic of the ViewModel. Therefore, it is clear, that you should use a Publisher(Model)-Subscriber(ViewModel)-pattern (events). That's all. So, as an answer to your question: How to set up the communication between Model/ViewModel depends on your style and the specific task:
If you just want to react on changed properties, just use INotifyPropertyChanged, as that's what it was made for. In the ViewModel, just subscribe to the PropertyChanged-event of the Model and process the changes, which is basically just 'map them forward', that is raise PropertChanged for the ViewModel-property, which is effected by the change of the model property.
Alternatively, if you need to wrap the model changes in a more specific event, lets say 'MyDataUpdated', then I don't see any problem about that as well. Just listen to this event in the ViewModel, and handle it as you wish. That's perfectly fine to.
I hope this helps.
EDIT: As a side-note: I recommend using the PropertyWeaver extension, so that you donÄt mess up your model with all the PropertyChanged-stuff.

I will go with option1. Keep a reference to the model in your viewmodel, however do not use any properties directly. Instead, populate the viewmodel's own properties from the model.Your view model can listen to the property changing notifications for the concerned properties from the Model, and repopulate its own properties from the model. The model is still UI independent, it is merely notifying property changed.
In my opinion, doing your own publisher-subscriber logic other than inotifypropertychanged could be just an overkill as there might not be any benefits doing that. However, this depends on whether you can afford to have a model reference in the view model and my answer is based on the assumption that you can have a reference of model in view model.

For for data binding you can use **Binding**
Data Binding Overview