I am trying to get into MVVM and away from the code behind approach in Silverlight, and I want to know the best practices around how to invoke view logic.
I have a very basic page where I have bound a listbox to a collection of domain objects, this is all using MVVM, so when I recieve my data back from the services, I want to fire off an animation and view changes on the screen.
Where/How is the best way to doing this? Silverlight (version 3, BTW) doesnt have triggers does it? I have seen blogs where people seem to be using them, but i think they must be rolling their own? Not sure... anyways, any thoughts ideas here is greatly appreciated
First of all, I think code behind is just fine as long as it only works with the view, i.e. it is concerned only with UI concerns. Don't struggle for no-code-behind when the easier way out is just as correct.
Secondly, of course sometime you need some sort of disconnected communication between your view and view-model (for example, getting multiple selected items from your view into your view-model). For these purposes you could use an aggregator like MVVMLight's Messenger, which is both simple and expresses the concept nicely. You can send a message from the view-model and have the view listen for it; also you can send messages from your view (when some events occur) and broadcast them.
MVVMLight also includes some utility classes which make it easy to bind events directly to Commands in your view-model, so that's the easier option in most cases I think.
Related
I dont hope to get any answer but i will try to be clear.
I tried Caliburn Micro . At first it seemed fine and all i need. Some features yes but other not.
All i wanted is a single window with some views as usercontrols and multiple dialogs at each view. Using a conductor.OneActive i could achieve the first with little pain. However switching between views even looking the example was to cast Parent to Conductor and call a method there.
Even example of caliburn micro did casting like this. Calling .close(false) at screen was same as close(true) resulting in killing the view and recreating causing lag in lowest end atom pc.
So only solution was to cast to parent.
Dialogs
I tried tons of dialogs examples but non worked and made my life hard.
Messagebox etc were DEAD easy but in case you wanted multiple dialogs you were out of luck.
If you put code at close callback to open another dialog you got bonus stackoverflow exception as it gets confused.(Endless loop).
I could figure a good dialog that could cache the view and at the same time to display efficiently multiple dialogs.
Event Aggregrator
Also i cant figure out how on earth event aggregrator is suitable for switching views. In case you have multiple conductors it could be a hell to manage.
To show a dialog - as in Modal Dialog that blocks the view that showed it - you should be using IWindowManager.ShowDialog.
You should take a look at prism library http://compositewpf.codeplex.com/
see navigation chapter: http://msdn.microsoft.com/en-us/library/gg430861%28v=pandp.40%29.aspx
But I don't know how EventAggregator could help you to switch views… you could subscribe to received an event on a closingView but… …
You might want to take a look at Catel. It has a UIVisualizerService which allows you to show windows based on their view model.
It also has a ViewManager (IViewManager) which allows you to manage all views inside your whole application. Besides that, it also provides a ViewModelManager (IViewModelManager) which does the same for your view models. Best of all: you can find all views that are connected to a specific view model in your application to interact with that.
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 like the concept of REST wherein each page is stateless. However, I haven't seen anyone using it in windows application. Way back, when I'm still using MVC and MVP patterns, one of my setbacks is handling states.
I don't know if this is a good idea, but I like to know your opinion on this. :)
Thanks.
I guess it depends on how you implement this. My view models typically keep state in properties that the views can bind to. However, I have sometimes found it useful to keep that state information in a separate object, which my view model hangs on to. My view can still bind to it and it declutters my view model.
I've built two large winforms apps using REST and I'm starting to experiment with WPF. WPF should be even easier.
I use MVC on the server for my REST resources and MVC on the desktop.
I have a multi-part question:
(1) Is there a good reason why Silverlight doesn't expose a DataContextChanged event? It seems like a whole lot of hassle could be avoided if someone at Microsoft just changed internal to public in the FrameworkElement class (like WPF does).
(2) I've found one or two different methods for hacking your way into a DataContextChanged event by using DependencyProperties in one configuration or another. But I can't get them to work reliably. My testing so far seems to show that they fire the hacked DataContextChanged event just fine for the first class to which I hook them up, but don't fire for any other classes. Has anybody else run into that problem? Or better yet, have they worked their way around it?
(3) The reason I've been giving myself for wanting to know when my DataContext has changed is that there are some UI operations that are complicated to get right in XAML, but are trivial in code-behind; and for many of those things, I need to handle events raised by my ViewModel; and hence I need to know when my ViewModel has changed, so I can wire up the event handlers. Is this an accurate view of the world? Or is the fact that I'm wanting to deal with this sort of thing in code-behind a pretty good indication that my thinking has gone off the rails some ways back? I'm no MVVM purist: I just want to get from here to good code quickly, and I don't particularly care how I get there. Code-behind has served me reasonably well for over a decade now, and I'm loth to abandon it entirely. But is my pragmatism making it harder on myself at this point?
"But is my pragmatism making it harder
on myself at this point?"
I wouldn't call it pragmatism. I'd call it fear of change; staying in your comfort zone. Life is actually far easier if you abandon your old way of thinking and embrace the new (and I know exactly what you mean - I was in the same boat as you with code-behind).
Now, off my soap box and to a more practical answer:
When you want to detect changes in your model, then hook into the events that allow you to detect changes in your model. The DataContext is not really the model... All of your model objects are going to have an implementation of INotifyPropertyChanged. You should either be hooking into that for a given model, or hooking into something similar for an ObservableCollection.
Silverlight/WPF make all of this sort of stuff WAY easier now that databinding actually works.
Don't fight the framework. Don't bring old ASP.Net practices with you to this game... It will not help you. You'll lose the best parts of the framework's power that way.
Cheers.
I have a 3rd party control which among other things performs loading of some data. I want my viewmodel to keep track of this load operation and adjust its own state accordingly.
If it were up to me, I'd do the data loading far away from the view, but it is not. So, I seem to be in the situation where my viewmodel depends on my view. How do I best handle this? I feel rather dirty making the view publish events to the viewmodel but I don't see any other reasonable way to get this info into the viewmodel.
A similar situation might crop up with standard controls, too - imagine if your viewmodel depends on the events coming from a MediaElement - how do you properly model this? Do you put the MediaElement into the viewmodel? That doesn't sound right.
If publishing the events to the viewmodel is indeed the most reasonable way, is there some common pattern used for this? How do you do it?
Generally, you would not allow your ViewModel to know details or even the type of your view controls. Having it respond to events is the cleaner way to go. There are a number of libraries that contain behaviors to map control events to ICommands on your ViewModel.
Caliburn is one such library. You can map control events to methods on your ViewModel.