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.
Related
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.
I am trying to find the way to build complex web pages with MVC3 and AJAX.
I would like to use components to achieve this.
Each component is consisted of it's own model, view and controller.
Multiple components are then placed on some complex view and should act together to
provide desired behaviors.
In some situations, when user performs some action (interaction) with one of the components,
I must update other portions of the page via AJAX.
Component on which action (interaction) occurred, in it's implementation, does not assume anything about view on which it will be used and what portions of the pages should be updated and how.
So when some interaction occurs in some component, I need a mechanism (outside component itself) which will handle this situation and update appropriate parts of the page.
How would you, generally, implement such mechanism?
I would use the Mediator Pattern, also sometimes mistakenly referred to as the manager pattern.
This class would mediate the communication of your components.
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
Is MVC architecture appropriate for an app that is a UI centric app?
Example: you want to build a basic flowchart app. Does it make sense to make the GUI components the view, the "node" and "line" objects part of the model, and the click handlers the controllers?
It feels weird to me because there is not much functionality in the model here...
In your case, M is definitely not needed. So you can skip it. Nobody is forcing you to comply with MVC.
If you're using a MVC framework, then don't use features specific to M. Simple. :)
I think it would be pretty useful to use mcv in your project instead!
You have to store somewhere the input data of your charts so a model object would be ideal for that.
The view class would be a template for the boxes and every instance would have is coordinates.
Separating the data from the boxes view would allow you in the future to change aspect and behaviour of the box view without having to touch the data.
In the end you have to consider the mvc pattern not as something that help you build your application in the current state, but a way to have a clean design that you can change and improve without having to rewrite everything. So if you want to build an app that is going to grow go with MVC.
In MVC, do controllers belong with an application, or can they go into a shared library? For example:
//this is a shared library
LibShared
//these are two apps
appA ->LibShared
appB ->LibShared
Shouldn't each app implement its own MVC and use any shared libraries as perhaps part of the app's logical model or simply another library reference (utilities)?
Also, is there ever a situation in which an MVC Controller is stuck in a shared library? I thought Controllers needed specific views located in a specific app. Meaning, the Controller must go in that app?
Or can Controllers be generic (i.e. shared library)? Doesn't that mean they are no longer Controllers?
I would advise that you should only be separating out your controllers into their own module/package/library (herein referred to as modules) if you have a requirement to do so (i.e. immediate re-use). If no such requirement exists at present then I would defer the decision to when it is required, it sounds in your case you are about to unnecessarily over-engineer. It should in theory be possible to refactor later to a separate modules without much hindrance, however be careful regarding coupling, separating out to different modules doesn't reduce the coupling, look carefully at your dependencies at how much the controller is orientated to one style of view.
one liners answers to your question to your application is
YES, YOU CAN MOVE YOUR CONTROLLER TO A SEPARATE LIBRARY WITHOUT A SINGLE LINE CODE CHANGES.
I suppose any code can go anywhere, what would drive us to put something in a shared library or keep it with the app?
I would consider two things:
1). What's the rate of change? When we change the app overall is this likely to change.
2). Could anything else need to use it? If so when I realease a new version would the other client immediately
Typically a controller would be strongly associated with the application and hence not of much interest to any other app, and it's probably fundamental to the app changing as the app changes. Hence packaging with the app makes sense.
Now if the conroller is somehow more generic, perhaps configuration driven then shared library makes sense.
Controllers does not necessarily needs to be even in the same operating system. You could have a view in Windows, a Controller in Unix and your Model in a Sparc. Remember MVC is just a pattern, a way you could do something which is more robust and easier to modify.
Your controller could be a shared library. Does your controller should be aware of your views? Not necessarily. That depends on how you handle the communication between modules. On a good MVC implementation, modules simply interchange messages or events. So, a View send an event to the Controller, the Controller decides what to do and send a message back. The response of the controller could be something like "Show Window X". Be advised that "Window X" could be interpret by the View module, if the View is an a Web module, then the View just put the proper aspx page. If you have another view who happens to be a web application the renders Form X.
At least in CakePHP and in the architecture that Mike McShaffry explains in his Game Coding Complete book the controller does belong to the application.
However, in both cases the architecture is such that the application inherits the basic functionality of a model, view, and a controller from the framework.
Eg.:
// "super" controller of all applications using this framework
class Controller
// uses basic libraries that allows the inheriting applications to work minimally
class AppController extends Controller
// mainly uses the parent class's methods but can also substitute to using
// additional libraries
By framework here I mean the system that encapsulates the use of libraries. In CakePHP this encapsulation in turn is done by using libraries in the respecting models, views, and controllers. So neither of those components is free from attachment to libraries.
In Mike McShaffry's architecture however, only the controllers and views use libraries. So the models are left uncoupled and are thus highly portable to different applications.