I am fairly new to MVVM.
I find a lot of examples, where ViewModels can publish events to other VMs using event aggregations.
My question is: Can I use the event aggregation to publish an event from a model, service or helper class, and VMs are reacting to it?
Example:
Helper class using tapi3.dll to implement tapi features. I now want to sent the TAPI_EVENTS as events to VMs to react to incoming calls (e.g. display different Usercontrol)
Is this possible? Or do I break the MVVM pattern?
Thanks!
Related
With Castle Windsor every component is tracked by default, even if it's the lifestyle is configured as transient. How do I deal with this in a WPF MVVM application? I don't want to create (or register using the Typed Factory Facility) a factory for every ViewModel type and release every instance I create, but I accept it if that's the only solution.
I know about the NoTrackingReleasePolicy, and I also know that using it means you're probably doing something wrong, but could it perhaps work for MVVM with singleton services and transient ViewModels only?
Is there perhaps a possibility to use child containers for the ViewModels which use the NoTrackingReleasePolicy?
Sometimes a Domain Model object with a business logic (DDD) when calling a method an event is fired.
In my situation, a viewmodel (for a given view) encapsulates the domain object and needs to register and react on those domain events (i must use events because that same domain object can be managed by many loosely coupled views along with their viewmodels).
I also need to unregister to those events when that particular context is hidden.
I can handle this register/unregister/dispose in parallel with show/hide/dispose of that view using databinding, programmatically or whatever if the scenario keeps simple enough...
The problem comes when visualization logic comes with DataTemplates.
How can I know when that datatemplate becomes hidden so that I can unregister my events? is it there a better way with wpf to handle this, instead of adding more events?
What is the best practice to handle this scenario in a good MVVM approach?
edit: ok, the problem is structural. sometimes choices made inside the project has forced us to work in an atypical manner... in a good mvvm approach this problem should not happen
I'd be careful in making the ViewModel dependent on the View for making things right.
So what I would do is provide a property (Show? Visible? Open?) on the ViewModel that has a TwoWay binding with the View so the ViewModel can monitor the property.
I have what, on the face of it, seems to be a really simple requirement - to be able to show a messagebox from within the view model of my WPF prism application.
Reading the documentation everything sounds good when I'm reading about Interaction Requests but I then find out that WPF doesn't support PopupChildWindowAction.
How are people getting around this. Basically I want a Messagebox in my shell module / or a infrastructure module that will subscribe to events and popup when that event is published.
Another issue I had was I want the popup to be centered on the parent window (the shell).
Just wondered how other people approached this. There seem to be a number of different ways to go but neither seem to fit the bill exactly.
From A CodePlex post by Karl Shifflet:
I've written a WPF version of the Interaction Request for my the Box MVVM Training here:
http://visualstudiogallery.msdn.microsoft.com/en-us/3ab5f02f-0c54-453c-b437-8e8d57eb9942
Install this Visual Studio Extension.
Create a new project with the MVVM Training Template.
Check out DialogInteractionRequestView.xaml and its implementation.
Cheers,
Karl
Use the RegionPopupBehavior from Prism 2.2 RI.
Use the EventAggregator in PRISM to subscribe to events, and have an in-memory presenter that listens for an event and then creates a view using the event data and calls ShowDialog on the view.
The dialog result can then be used to publish a 'response' event that would be routed back to the process that initiated the event that resulted in the display of the dialog.
Since PopupChildWindowAction is only in Silverlight, I have created my own PopupAction by inheriting from TriggerAction class and simply overridden body of Invoke() method to bring up a PopupWindow where I can pass any UserControl from xaml within the prism interaction trigger tag. From within ViewModel I am raising interactivity request event which triggers my PopupAction in view and opens the popup with desired user control being displayed onto it. Seems to work. I'll need to polish the example more. But here is a link -
http://wpfgrid.blogspot.com/2013/01/simple-prism-mvvm-way-to-display-dialog.html#step3
I'm using EntityFramework for data access and wpf as UI. If I bind WPF components to navigation properties of my entity classes(usually EntityCollection<EntityClass>, exposed as IList<T> in service layer), UI is not updating the changes. I know i have to use ObservableCollection<T> or such, but I need some guidance on how to use it without iterating back and forth upon save and retrieval processes.
(As you guessed, I'm new to WPF; so target your answers for a WPF beginner)
You don't have to use ObservableCollection. WPF actually depends upon INotifyCollectionChanged, which ObservableCollection implements. So if you create a wrapper collection which implements this interface and forwards the operations onto the EntityCollection and raises the events, you should be good (as long as you modify the collection via the wrapper and not the underlying collection. A similar concept is used for read-only collections (wrap an existing collection and interact with wrapper), simple Decorator pattern.
You can't use it directly (and have the changes be reflected).
Here is a link that explains how someone else solved this problem
I faced the same problem in Silverlight LOB applications
I've created a silverlight library called ObservableCollections accompanied with visual studio 2012 addin and NUGet support, to generate the boilerplate code in order to wrap the EntityCollection with ObservableEntityCollection class, I know your question is about WPF but it could help.
http://observableec.codeplex.com/
I'm building a WPF app and trying to conform to MVVM best practices. I'm using the MVVM Foundation framework and noticed the Messenger class, which I've read should be used for handling dialogs in WPF. This sounds great, but I'm totally not understanding how to use a Messenger for this purpose. Literally, all I want to do is open a modal About dialog --I don't need to pass any messages back and forth.
Was the intent of the Messenger class to be used for cases where dialogs require a message from its parent, or return a message to its parent? Is it overkill for an About dialog? Would I be better off simply adding code to an event handler to show the dialog?
The idea behind the messaging pattern doesn't specifically have anything to do with showing dialogs. The idea is simply to provide a decoupled way to communicate between ViewModels.
You can leverage this infrastructure to solve your problem but you will have to implement the showing of the dialog yourself.
As Phillip showed above you can send messages between ViewModels. When your ViewModel receives the message it can set it's own internal property, say "ShowDialog", to true.
You can then have a binding that reacts to this property change operation and opens a dialog.
I have also built a simple messaging framework for the MVVM pattern that borrows from Josh's idea (and several other existing frameworks) you can read about it here
Say you have a parent view and a dialog view. In MVVM they would both have a view model. It is good to keep these view models decoupled, i.e. they don't have references to each other. And yet they need to communicate to each other. The Messenger class acts as a go between or Mediator to mediate the communication of information between the two classes. See the code taken from Josh's blog.
Here is Object A. It's call to the mediator's Register method implements: when I receive the message ObjectBSaidSomething, from the mediator, I'll cache it in the member WhatObjectBSays.
Here is Object B, which implements: I'm going to send a message ObjectBSaidSomething. Note, that Object B knows nothing about Object A. There might be nothing listening for ObjectBSaidSomething, or 100 objects listening for ObjectBSaidSomething, but Object B doesn't know and doesn't care. This is good decoupling, and this is why the Mediator pattern is a good idea. And this is the way the MVVM foundation is recommending that information is passed between view models.