Hmm ...MVVM ... Is this Bad? I can't decide
-
Hey All, I'm just looking a spot of MVVM and I've written a little demo app with this interface in:
public interface IView where T : ViewModelBase { T Model { set; } }So in my windows I can do this:
public partial class MainWindow : IView
{
public MainWindow()
{
InitializeComponent();
}public MainWindowViewModel Model { set { DataContext = value; } } }And it will automatically type my Model property for me ... amazingly lazy but I kinda like it. I'm just not sure how 'MVVM' it is ... What are your objections? This isn't an interface for every ViewModel type but works well for Window / Region / Views (proper) type view models ... Cheers,
Jammer My Blog | Articles | DMon | SampleSort
-
Hey All, I'm just looking a spot of MVVM and I've written a little demo app with this interface in:
public interface IView where T : ViewModelBase { T Model { set; } }So in my windows I can do this:
public partial class MainWindow : IView
{
public MainWindow()
{
InitializeComponent();
}public MainWindowViewModel Model { set { DataContext = value; } } }And it will automatically type my Model property for me ... amazingly lazy but I kinda like it. I'm just not sure how 'MVVM' it is ... What are your objections? This isn't an interface for every ViewModel type but works well for Window / Region / Views (proper) type view models ... Cheers,
Jammer My Blog | Articles | DMon | SampleSort
-
It's probably not that useful: it's rare that you want to manipulate a view's view model – what a mouthful that is – in a generic way, through ViewModelBase. But I think it's quite elegant, and it clearly shows (and enforces!) the M-VM relationship.
Yeah, it really is a 'swings and roundabouts' kinda issue isn't it ... Strictly speaking the view still doesn't now anything about the model. The only thing it does know in this scenario is the type it will accept as the view model. 99% of the time your unlikely to want to be switching the type of view model you inject into the view data context. The only thing I don't like is you now only deal with concrete types for view models rather than an interface.
Jammer My Blog | Articles | DMon | SampleSort
-
Yeah, it really is a 'swings and roundabouts' kinda issue isn't it ... Strictly speaking the view still doesn't now anything about the model. The only thing it does know in this scenario is the type it will accept as the view model. 99% of the time your unlikely to want to be switching the type of view model you inject into the view data context. The only thing I don't like is you now only deal with concrete types for view models rather than an interface.
Jammer My Blog | Articles | DMon | SampleSort
To be honest mate, if I were you I would use MefedMVVM instead. It gives you the type to interface, and takes care of hooking up the concrete implementation for you.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
To be honest mate, if I were you I would use MefedMVVM instead. It gives you the type to interface, and takes care of hooking up the concrete implementation for you.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Hey Pete, Will look into this. Looks good! Cheers,
Jammer My Blog | Articles | DMon | SampleSort
It is - I did a minor part of the development for Marlon. It's top notch stuff.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
It is - I did a minor part of the development for Marlon. It's top notch stuff.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
It is - I did a minor part of the development for Marlon. It's top notch stuff.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Hey All, I'm just looking a spot of MVVM and I've written a little demo app with this interface in:
public interface IView where T : ViewModelBase { T Model { set; } }So in my windows I can do this:
public partial class MainWindow : IView
{
public MainWindow()
{
InitializeComponent();
}public MainWindowViewModel Model { set { DataContext = value; } } }And it will automatically type my Model property for me ... amazingly lazy but I kinda like it. I'm just not sure how 'MVVM' it is ... What are your objections? This isn't an interface for every ViewModel type but works well for Window / Region / Views (proper) type view models ... Cheers,
Jammer My Blog | Articles | DMon | SampleSort
Personally, I'm more a fan of including a controller in there. I kind of mix MVVM and MVC together. My class defenitions then look like this:
public class SomeController : Controller
public class SomeModel : Model
public class SomeView : View, ISomeViewIn the constructor of the view, I'll create the controller, which exposes a model property. That model will then be set on the datacontext. When creating the controller, I'll pass the view to the constructor so that the controller has a reference to the view as well (under the form of an interface). This way, you can unit test the controller and assert your model states while mocking the view... and, you won't have any ugly code-behind in your *.xaml.cs file, aside from some eventhandler methods like a button_Click. And in those methods, you'll only have 1 line anyway, which will be a controller call like Controller.XButtonClicked() or whatever. For LOB applications, this works great. This also opens up a lot of possibilities for standard control behaviour you may wish to have like automatic busy indicators etc.
modified on Thursday, April 28, 2011 8:10 AM