We Keep Coding

Event-based communication between "sibling" views

I'm pretty new to WPF so I've been struggling with some basic concepts.
My application consists out of a main window containing various tabs. The first tab is used to add files, activating the other tabs which operate on the given files. For simplicity, let's call the latter "DataTabs".
I'm not sure about how to correctly communicate between the tabs. Currently, the FileInputTab uses a designated ICommand to do the following: Read the data, create a view model for the DataTab, and raise a "ViewModelReadyEvent" using the FileInputTab's view.
This event then bubbles up to the MainWindow, which activates the DataTabs and passes the created ViewModel on to them.
Now, two things I'm struggling with.
Populating the view model
Is it a better approach to populate the view model for the DataTabs inside their corresponding views, rather than from the FileInputTab that actually has nothing to do with it? This way, I could correctly establish a reference between the two, but I would have to perform the population separatly for every DataTab. Any thoughts?
Communication between "sibling" views
It doesn't feel right to let the event bubble up all the way to the MainWindow to let it orchestrate all inter-view communcation. I looked into RoutingStrategies, but I can't find any way to directly communicate between "sibling" views. I would like to raise an event in the FileInputTab and directly act on it in the DataTabs, without any intermediate.
Any thoughts, comments or book recommendations by WPF experts would be appreciated. Thanks in advance.

Using MVVM you could introduce a ViewModel for every tab. Then you could write a Service for the communication between the ViewModels. It is quite easy if you use the Messenger Pattern. One ViewModel sends a message to the Service and the Service leads it forward to the other ViewModel. The Service would also do the work, so your ViewModel would not have any business logic.
MVVM Light helps you a lot with the MVVM pattern.

You can use IEventAggregator to communicate between ViewModels.

How to communicate between two MVVM pairs?

I have a little app with a overview of some items (entries). The title of the entry at the list in the overview is a property of the entry.
When I click an entry a kind of tab should open where I can edit the entry. When I edit and save the entry, the overview tab should update the next time.
Here a mockup for better understanding.
App is based on MVVM pattern. Each View has a ViewModel as DataContext. Each ViewModel uses a Model and each Model has a Database.
The overview tab have it's own View, ViewModel and Model (pair). Also the tabs. Each tab for entries use the same pair (singleton instance). Only a few bindings are updated If a other tab is selected.
My question is how to communicate between the tabs.
I have two approaches
Mediator Pattern (Bootstrapper combines two ViewModels with a mediator)
Each Model uses the same Database (Models listen to Database, ViewModel listen to Model)
But I dont' feel well with these approaches.
Should I communicate between Models or between ViewModels? Or is this the wrong way?
UPDATE
I really appreciate all of your answers. In my opinion none of them are wrong or right. I think it's a matter of taste which solution is right for one is. I really like the EventAggregator pattern. Here is a nice video from Karl Shifflett about the implementation of the EventAggregator pattern in PRISM. But it also explains the pattern itself.
#Thomas In my opinion it is a bad solution to do this in one ViewModel. ViewModels have to be separated. MVVM based on Separation of Concerns.

Mediator is a step in a right direction but an Event Aggregator is much more flexible. You can find dozen of implementations. For example, Prism has a ready-to-use implementation.
Communication is between ViewModels. ViewModels register themselves for notifications in the Aggregator and raise notifications on the Aggregator.

You should communicate between ViewModels, if the functionality is related to formatting Model data for display. If your are communicating data from one Model to another, then communicate between Models.
Here is a concrete example: The Microsoft.Practices.Prism namespace, which you can access with NuGet right in Visual Studio, includes a class called CompositePresentationEvent<T>, along with an EventAggregator class which does the actual communicating.
Someplace common to your entire application (I chose App.xaml.vb, but it can be any publicly scoped code file, and it works as well for C# as for VB), you define events by inheriting from that class, and supplying the type T which corresponds to the data you're sending. For example, if you want to send a message that contains a simple string, then declare:
Public Class MyEvent: Inherits CompositePresentationEvent(Of String) : End Class
In your Application class, you define an event aggregator:
Public Shared ReadOnly AppEventAggregator As IEventAggregator = New EventAggregator()
Those two items together give you the means to trade events between any two objects in your application.
This gives your entire application access to an event called MyEvent. Wherever you want to send the MyEvent message, you call its shared Publish(String) method:
Application.AppEventAggregator.GetEvent(Of MyEvent).Publish("This is my event message")
Then, to receive the event, you implement a private read-only field in the class where the event should land, something like:
Private ReadOnly MyEventToken As SubscriptionToken =
Application.AppEventAggregator.GetEvent(Of MyEvent).Subscribe(Sub(eventMessage) DoSomethingWithTheString(EventMessage))
...where DoSomethingWithTheString(eventMessage As String) would be where you process your event.
There's (a lot) more to Prism, of course, but never a need to use more of it than you need, and, as others have pointed out, lots of other MVVM frameworks with similar approaches to solving the same problem.

For me, it's usually a bad sign when I have to program for communication between view models. Sometimes, you have to make communication between view and view model, but the need for connecting two view models seems to always result in combining two view models if possible.
With your mockup, I felt the same bad feeling. Why do you have to have separate view models for tabs in first place? In your case, views can be separate but I don't see any benefit from separating view models. Thus, combining the two view models into one is my recommendation.

Maybe this Post is interesting for you, it Describe a Pattern for a Communication on Type basis. It allows you to Communicate between everything you want, without dependences between them

Validation in MVP WinForms Application

I am creating a Windows Forms application that reads various tables from a database into a DataSet in order to display said tables in multiple DataGridViews. Rather than putting all my code in the code-behind file, I have started doing some research on different design patterns, and have found many articles/threads with the consensus that MVP is the best option for WinForms.
After doing a few tutorials, and starting to organize my code using the MVP pattern; I have placed my DataSet in what would be the Model, most of the logic in the Presenter, and everything else in the View.
My question is: where should I place the validation of user input? I do not want the user to be able to enter invalid values into the DataGridViews, and if they happen to do so, I would like to let them know the row/cell that has the error. Previously, I would handle the RowValidating event and check the row and cells of the DataGridView for any errors, and then display a message accordingly, but this seems to not fit within the MVP pattern.
Should I leave the validation in the view, or should it be moved elsewhere?

IMHO you should keep the view (the form) as simple as possible. You can indeed subscribe for the RowValidating event and call the presenter (presenter.ValidateRow(...)) from there and pass to it the info and let it handle the validation. The presenter on his turn can ask the model for some info if the validation logic happens to be complex and has to go all the way down (to the DB for example). It is the presenter's responsibility for how to handle the errors. When the validation process completes it's the presenter's job to call a method or set a property on the view in order to display failure or success. Remember that your view is just a "window" to the state of your business logic (objects). Ask yourself the question "Is my program going to work if I swap this specific view with another implementing the same interface but not written by me?".
You may want to take a look at this http://msdn.microsoft.com/en-us/magazine/ee336019.aspx article for further clarification on MVP pattern.

Struggling to understand MVVM architecture

I'm trying to learn MVVM and WPF and I'm using the MVVM Light Toolkit. Here's what I'm not fully understanding and maybe it's due to an incorrect architecture of my UI.
What I'm trying to accomplish is pretty simple actually. This is a utility application by the way. I want a window that serves as the 'controller' so-to-say that has a set of buttons. Each button should change the content of a frame. Example: one button loads a 'screen' ( or a 'view' if you will ) that allows the user to configure an 'Agency' which is a custom object. Another button loads a list of Users from the Agency that was in the first 'screen'. This 'Users' view needs to also be loaded in the same frame. In fact, as of right now, the window with all the buttons really is only responsible for loading the 'screens' in the frame. The meat of the application will be within all the separate 'screens'
What I am not understanding is 1) how to let each screen/view know about each other since one is dependent upon the other. It seems that in MVVM the ViewModel shouldn't know about anything. But in my case, I need to pass information around ( such as my Agency ).
If I can get some hints on what I need to look into, that would be great.
Thanks!

Some ideas that might connect some of the dots:
You'll most likely have one viewmodel per view ("screen").
Each viewmodel will contain all of the logic for its corresponding view
Viewmodels can and will know about the models (Agency, Users)
Viewmodels can communicate with each other via the Messenger in MVVM Light
Think of MVVM Light's Messenger as an "application-wide eventing system". When you send a message out from one view model, any other view model can be listening for that message/event and react to it as needed.
Does that help at all? Keep your thoughts coming and I'll keep commenting and I'm sure the community will as well :)

Few things:
each of your screens, should be separate view (eg. user control or new window - I suppose you've done that already)
every part of model (eg. Agency, User) you want to display in your application, should be wrapped with its dedicated view model
your views don't really need to know about each other; you can use commands or events on view models to get rid of those dependencies
view model only needs to know about one thing: model it's building on
it's good to think about view as really simple class, with one single responsibility of rendering content; no logic, no code behind (unless it's purely UI/display related) is something to follow
You can try to prepare your models first (if you haven't done that already), then make view models for them (thinking what properties of models you want to expose to views) and once that's ready, build your views basing on view models. Other way around is also viable option - pick whichever feels more natural to you.
One more thing: since you mentioned you can display several screens in one (I assume) main area, think about equipping your view models with something along the lines of bool IsCurrentlyActive property. This way, you can easily show/hide views with button clicks and still utilize binding mechanism.

They shouldn't know about each other. That is what the Messenger is for controllers and views subscribe to the events they are interested in. That way they don't need to know or care where they event originated.
Hmm Kendrick is faster. What he said.
Also it sounds like you kind of want an Outlook type interface, some navigation that loads other views. I had the same question a while ago. How to do Regions in WPF without Prism?

To better understand the MVVM pattern look at this article: WPF Apps With The Model-View-ViewModel Design Pattern
Also I advice you to look at Caliburn Micro framework.

Good architecture for consuming a REST web service in an MVVM app for Windows Phone 7?

I'm having a bit of trouble deciding on the best way to get the data from the web service to the UI.
Given the asynchronous nature of WebClient how would you build this?
Model uses WebClient to talk to webservice
ViewModel asks model for data
View is databound to ViewModel
On the Async complete event I need to get that data back out of the model to the ViewModel, these are the things I've thought about.
I could fire an event in the Model that the ViewModel subscribes to.
I could perhaps do something with passing around callbacks?
Or should I be doing a second level of INotifyPropertyChanged events between the ViewModel and the Model?
Or am I very confused and completely misunderstanding MVVM?

It depends on how purist you want to be about MVVM.
You could treat the API itself as your Model, in which case the ViewModel has the WebClient and on Async completed you'd set your properties (and they would in turn fire PropertyChanged from within their setters).
Or you can have a local Model that has the WebClient code in it (as it sounds like you have). In this case, my personal approach would to have a "ModelUpdated" event that fires from the Async complete event. (Your option 1).
Your ViewModel can listen for this event, and either fire a PropertyChanged(null) to have the View ask for ALL properties, or fire multiple PropertyChanged events. Remember you're not restricted to firing PropertyChanged from within your setters. There's nothing stopping you from having a method like
private void FireMultipleProperties(){
NotifyPropertyChanged("Property1");
NotifyPropertyChanged("Property2");
NotifyPropertyChanged("Property3");
}
So you could call that method when the Model finishes populating, and your UI will call update each property when they are fired. You'd only need to do this if you have a ton of properties and don't want to fire them all at once with PropertyChanged(null).

I think you need to introduce a new layer into your architecture; a service layer. Usually, I pass in my relevant services to my ViewModel and the ViewModel does the handling of the async calls and showing busy states and all that fun stuff.
For instance, if you have a Product Model, and ProductListViewModel with a collection of products and maybe a search command, then you would introduce a ProductSearchService (Or ProductLoadService that loads all products). I would then pass that ProductSearchService into your ProductListViewModel constructor (dependency injection) and let your ViewModel control the retrieval of the Products (your model objects) by calling the relevant service methods and loading the response.
ProductListService Returns Product (Model) List
ProductListViewModel uses ProductListService to get Products
ProductListView binds to ProductList ObservableCollection in ProductListViewModel.
This pattern essentially resembles Model-View-Controller, where the ViewModel takes more of the Controller responsibilities.
Since you mention REST based web services, I have an example blog post of using MVC 2 JSON results as a service layer for a Win Phone 7 app: Data Driven Win Phone 7 Apps with MVC 2 JSON services