I am involved in the development of a WPF Prism application which uses the event aggregator to send global type messages which are then picked up by the shell. For example, a viewmodel might want a toast message displayed but doesn't really care how it is displayed. In this instance the shell would be setup to process those events and act on them application wide.
The question I have is how do you do it if a particular view wants to display the toast messages differently. I like the global approach because it is very simple, but how to customize it for special cases?
I think this really depends upon how your application is setup and what standards/patterns you are using. In MVVM I see two approaches.
View-First
If your View-Model is injected into your view, then send the messages to your view, and let the View decide what to do with it. If it wants to display them itself, it can do that. If it wants to send them to your shell, it can do that through the event aggregator or injecting a Toast service interface. That keeps your View in control of the visual.
View-Model-First
If your View is injected into your View-Model, then your View Model should be asking for a different View, which should be bound to its own View Model. If it wants to send messages to another View-Model, it can do that through the event aggregator or injecting a Toast View-Model/service interface. That keeps your View-Model in control of the navigation between Views.
I prefer the View-First approach because it keeps your View in control of the visualization of your model. But I'm very interested in how other MVVM developers tackle this. This seems very closely aligned with the question of how to present dialogs in the MVVM View-First approach.
Using Eventaggregator for this purpose is not the right way I think, because the events are broadcasted to the entire application.
One possible way to handle the scenario is your viewmodels can get an IMessenger interface injected in the constructor. There is an application implementation of IMessenger(which is injected by default) and you can have customised implementations of IMessenger according to your needs. Your viewmodel just calls an interface function(say DisplayMessage()), but according to the Messenger injected to it, the behaviour is different.
Related
I need to write a GUI framework, where I have no experience at all, not even using one. I'm a programmer for 25 years now, but not touched GUI in OO.
My questions:
1. I'm using a special kind of programming language, where there is main event-loop that accepts all events and from there it has to dispatch the events. my question is, as a gui framework, to where I need to dispatch the event, for instance if a complex control like a List that has a scrollbar was scrolled, I get the event in my main event loop and I have to forward it to the complex control? or should it be routed to the scrollbar which is internal control in the List control, and then bubble it up to the List?
2. Apart from sending the event to the control that triggered it, for the sake of taking the standart internal response - is there another responsibility that the framework should handle? I mean, does the framework should bubble the event also to the Dialog control that will be inherited later by the framework user in order to impliment the specific response to the events? or is it left to the framework user to dispatch the event to the dialog? I guess what I'm missing is what is the framework responsibility in terms of reacting to internal events.
How to save state (eg. by PhoneApplicationService) and don't break mvvm principles.
When application goes to "deactivated" state I want to preserve model object (eg. bounded to a form) and restore it when application will be resume.
Where I should place a logic of "save state mechanism". In view or viewmodel?
Disadvantage place in viewmodel:
I want to use my mvvm in other platform (Win8) and I want to make my mvvm to be maximum independent from platform.
I been thinking about one event in viewmodel where view can be handled moment of model object creaction and save it in platform specific storage.
or
make service to save state based on interface and register it in ViewModelLocator.
I recently wrote an article about exactly this, and I created a NuGet package for this:
Article: http://www.kenneth-truyers.net/2013/03/13/tombstoning-made-easy-in-windows-phone-mvvm/
NuGet: Install-Package WindowsPhone.MVVM.Tombstone
You can read the article to see how to use the package.
The package basically allows you to apply an attribute to save all the properties upon tombstoning and restores them automatically. You just need to handle two page events.
In an WP app which approach is better.
From the .xaml page, call a method of another class (pass the delegate of a .xaml.cs callback Method ) which makes some request to server , receives data and when requests complete calls the .xaml.cs page method. and in call back method we get data and bind the data with a control (ListBox).
Bind the List box with an ObservableCollection object of MainViewModel class. and change the bounded object from the MainViewModel. All the calls to requests to server are made in MainViewModel class.
I vote for the option 2. Event the project templates (Eg. Databound application template for Windows Phone 7) gives you the MainViewModel and binds a Listbox to an ObservableCollection in that class.
The MVVC approach gives you a lot more flexibility, your UI is totally separated from the logic. ALl your UI needs to know is that it is bound to an ObservableCollection and it doesn't need to know how that collection is filled.
I think you should use the second approach which allows you to create loosely-coupled applications. The big advantages of such applications are:
separation of concerns: different subsystems/layers are independent
unit testing is simple
refactoring is easier
increase ability to code reuse
...
Regarding WP7, you can read my article which shows how to code using this approach:
a framework for building of WP7 application
I am new to GWT and getting back to programming after long gap...my question is about MVP implementation in GWT, I have gone through the following post and they were quite helpfull, but i still have some doubts
What are MVP and MVC and what is the difference?
What's your recommendation for architecting GWT applications? MVC, MVP or custom messaging solution?
i think the GWT tutorial (http://code.google.com/webtoolkit/articles/mvp-architecture.html) of MVP also has contoller (AppController ) in place and some of the responses are managed at Contoller level not at presenter. So my question is what should be the role of Controller in MVP pattern implementation?
From where should we initiate the async server call, presenter or controller , say if i have to save the record should i call the server function (which calls the DAO and saves the record) from Presenter or should presenter post event using event bus and conroller act on the event and calls server function for saving.
The GWT tutorial page you linked to says about the AppController:
To handle logic that is not specific
to any presenter and instead resides
at the application layer, we'll
introduce the AppController component.
So it's the glue between multiple Presenters, Views and the Model (maybe multiple Models). It also handles the browser history. And maybe additional things that aren't specific to one presenter.
As for the server call: There are several options, but I personally wouldn't do it from the view, and also not from the presenter - I'd use a model listener. The reason is, that multiple views and presenters can work together on one model. And when they change the model, that change should be sent to the server. Maybe you don't want to do that immediately, but collect a few changes before you send them. In that case, you could have a timer that's set up - well - by the AppController.
Answering to your last paragraph, I would say you should do it in presenter if there is something (some button) on view that is supposed to do it. Presenter is logically strongly tied to view (technically it should be weakly tied, by interfaces only not by implementations). If you want to save the record on some action which is not explicitly called from view, I wouldn't do it in presenter.
What are some lesser known tips for implementing a loosely-coupled MVC structure in a non-trivial desktop application (e.g. having at least two levels of views/controllers and more than one model)?
Use interfaces.
A lot. I like using the "IDoThisForYou" style (even in a language where this isn't idiomatic) because an interface represents a role that another class can use.
Make the controllers responsible for controlling interaction
The controllers control interaction between domain objects, services, etc.
Use events to pass information between controllers
Let every controller who needs information subscribe to the event. Use an interface.
Don't put presentation information on your domain objects
Instead, allow the controller to create a presenter or view model which has the information you need. This includes no "ToString()". If you're in a language without multiple inheritance you might end up with a bit of duplication between presenters. That's OK - duplication is better than coupling, and the UI changes a lot anyway.
Don't put logic in your gui
Instead, allow the controller to create a presenter or view mdoel which has the information you need. This includes train wrecks like "MyAnimal.Species.Name" - make it present "SpeciesName" instead.
Test it
Manually. There is no substitute. Unit and acceptance testing goes a long way, but there's nothing like bringing the app up and actually using the mess you wrote for finding out how messy it is. Don't pass it to the QAs without having a go yourself.
Oh, and don't mock out domain objects in unit tests. It's not worth it. Use a builder.
Declare event handlers in your interfaces (important for the views). This way you can loosely couple event handling which is managed by the controller. You may need to use the InvokeRequired when working with the view if your application is multi-threaded.