MVVM
-
Hello all, I'm fairly new to Silverlight and MVVM and I'm struggling with the correct way of doing the simple task of changing the top level silverlight view. Using Silverlight 4 commanding I am binding a command on my view model to a login button on my main form and then calling an authentication service to ensure the credentials are valid, this is working and I can authenticate the user. What I am struggling with is the best way of closing the login screen and displaying another screen when I get a successful response from my service. From what I understand you cannot hook a callback event in the view to a command object and I should also be trying to avoid having any code behind in the view so where do I control the opening of a new view? Obviously, my ViewModel should know nothing about the view so I can't do it there, can I? The way I was going to approach it is still use the button bound to a command on the view model but use a bit of code in the view to hook an event to the view model which is fired when I get the successful login from the service. The event hooked up in the view would then control switching the views but from the examples I have looked at I am not convinced this is the best way forward. Am I missing something obvious or looking at the problem in completely the wrong way? I'm hopeful this question will have a straight forward answer but after hours of browing examples on the web I'm still none the wiser as to the correct approach.
-
Hello all, I'm fairly new to Silverlight and MVVM and I'm struggling with the correct way of doing the simple task of changing the top level silverlight view. Using Silverlight 4 commanding I am binding a command on my view model to a login button on my main form and then calling an authentication service to ensure the credentials are valid, this is working and I can authenticate the user. What I am struggling with is the best way of closing the login screen and displaying another screen when I get a successful response from my service. From what I understand you cannot hook a callback event in the view to a command object and I should also be trying to avoid having any code behind in the view so where do I control the opening of a new view? Obviously, my ViewModel should know nothing about the view so I can't do it there, can I? The way I was going to approach it is still use the button bound to a command on the view model but use a bit of code in the view to hook an event to the view model which is fired when I get the successful login from the service. The event hooked up in the view would then control switching the views but from the examples I have looked at I am not convinced this is the best way forward. Am I missing something obvious or looking at the problem in completely the wrong way? I'm hopeful this question will have a straight forward answer but after hours of browing examples on the web I'm still none the wiser as to the correct approach.
DoctorMick wrote:
Obviously, my ViewModel should know nothing about the view so I can't do it there, can I?
There could be a few ways to handle this. An easy approach would be to use the navigational framework. But this does not provide the decoupling you are talking about. You cannot let your viewmodel know about the new view that you would want to launch, but you can let it know about the viewmodel for it. Create an instance of the view using the viewmodel. All this is based on the assumption that you are using the "viewmodel first" approach while implementing MVVM. If you want to decouple a little more than that, use a common controller class that handles all view / view model creations - this way all your view model knows about is this common controller class - nothing else. A fourth approach could be to use the
EventAggregatorpattern implemented by Microsoft Prism. Prism provides very high level of decoupling, but then there is a learning curve attached to the features it provides.Me, I'm dishonest. And a dishonest man you can always trust to be dishonest.
Honestly. It's the honest ones you want to watch out for...