MVVM Blues...
-
This is not really a question... When working with WPF trying to implement the MVVM pattern, I feel like I spend all of my time writing code to jump through hoops so as to not violate the MVVM pattern's principles... :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
This is not really a question... When working with WPF trying to implement the MVVM pattern, I feel like I spend all of my time writing code to jump through hoops so as to not violate the MVVM pattern's principles... :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
I feel the same way when starting a project. But once I get going, it does not seem so bad.
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Individuality is fine, as long as we do it together - F. Burns
-
This is not really a question... When working with WPF trying to implement the MVVM pattern, I feel like I spend all of my time writing code to jump through hoops so as to not violate the MVVM pattern's principles... :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
It sounds like you are writing a lot of your own plumbing code there. Why not try a library like MVVM Light, or Cinch? These take a lot of the pain away for you.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
This is not really a question... When working with WPF trying to implement the MVVM pattern, I feel like I spend all of my time writing code to jump through hoops so as to not violate the MVVM pattern's principles... :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
I feel the same way. It seems as though most of my time is spent on the architecture and implementing the pattern correctly. Then the actual core functionality of the application. But then again once all that is set up. Your life is made easier with unit testing etc.
-
It sounds like you are writing a lot of your own plumbing code there. Why not try a library like MVVM Light, or Cinch? These take a lot of the pain away for you.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Thanks Pete. I may give them a look. For my first go, I was trying to stick to basics, thinking that maybe it would help me understand things better, but now I see that I am getting buried in the niggling little details. My other concern was trying to learn one more thing (i.e. MVVM Light) on top of everything else. I looked briefly at Caliburn Micro, and my head started spinning round, and I threw up my hands and said, "Run away!" :) Now that I have a better feel for the basics, I might take another look at it (C.M.) at some point, but I think one of the ones that you suggested might be better for me at this point.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Thanks Pete. I may give them a look. For my first go, I was trying to stick to basics, thinking that maybe it would help me understand things better, but now I see that I am getting buried in the niggling little details. My other concern was trying to learn one more thing (i.e. MVVM Light) on top of everything else. I looked briefly at Caliburn Micro, and my head started spinning round, and I threw up my hands and said, "Run away!" :) Now that I have a better feel for the basics, I might take another look at it (C.M.) at some point, but I think one of the ones that you suggested might be better for me at this point.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
No problem. I've written a couple of MVVM frameworks so I know the pain you've been going through. Had there been a mature, stable framework around when I first started, I wouldn't have bothered as I'm not a fan of reinventing the wheel.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
No problem. I've written a couple of MVVM frameworks so I know the pain you've been going through. Had there been a mature, stable framework around when I first started, I wouldn't have bothered as I'm not a fan of reinventing the wheel.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
I wrote my own MVVM framework probably 6 to 8 months ago. There were 10 to 12 open source ones available. I chose to reinvent (and improve) the wheel. 1) I didn't want the code cluster f*cked up with Silverlight (and other nonsense) support since I have no interest in that and it's a dead platform anyways 2) No MVVM framework out there provided 100% of the plumbing needed to write a full blown MVVM application. 50%? Absolutely. 75%? Probably. 90%+, sorry, but no. You'd have to combine 3 or 4 open source projects to get to where I'm at I think. Now granted, I may not have all the features of those 3 or 4 projects combined, but I have what is needed to write a full blown MVVM application and they don't. For example, none of them have a way of binding to multiple selection tree / list controls which I found to be quite important :).
-
I wrote my own MVVM framework probably 6 to 8 months ago. There were 10 to 12 open source ones available. I chose to reinvent (and improve) the wheel. 1) I didn't want the code cluster f*cked up with Silverlight (and other nonsense) support since I have no interest in that and it's a dead platform anyways 2) No MVVM framework out there provided 100% of the plumbing needed to write a full blown MVVM application. 50%? Absolutely. 75%? Probably. 90%+, sorry, but no. You'd have to combine 3 or 4 open source projects to get to where I'm at I think. Now granted, I may not have all the features of those 3 or 4 projects combined, but I have what is needed to write a full blown MVVM application and they don't. For example, none of them have a way of binding to multiple selection tree / list controls which I found to be quite important :).
SledgeHammer01 wrote:
No MVVM framework out there provided 100% of the plumbing needed to write a full blown MVVM application. 50%? Absolutely. 75%? Probably. 90%+, sorry, but no
So what was missing? What features did you need that you couldn't get? Why could you not extend what was available?
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
SledgeHammer01 wrote:
No MVVM framework out there provided 100% of the plumbing needed to write a full blown MVVM application. 50%? Absolutely. 75%? Probably. 90%+, sorry, but no
So what was missing? What features did you need that you couldn't get? Why could you not extend what was available?
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Only a few "biggies", but most are the little bells and whistles: 1) no clean way to bind (both 1-way & 2-way) to a multiple selection list control (this is actually a WPF shortcoming, but my MVVM framework fixes it) 2) no clean way to 2-way bind to the selected item in a tree control (another WPF shortcoming) 3) no built in light weight DI container 4) no clean way to bind to item right clicks for context menus (without retemplating the item) 5) no way to bind to a password box 6) no single instance only support 7) no way to close a dialog or window from the VM 8) no way to disable the close on a dialog or window 9) no way to remove the window icon 10) no template-able task dialog Thats just from a quick scan of my code base :). Don't get me wrong... sometimes I grab code as a foundation and build upon it... but in this case, I looked at the various code bases and decided I would start from a clean slate.
-
Only a few "biggies", but most are the little bells and whistles: 1) no clean way to bind (both 1-way & 2-way) to a multiple selection list control (this is actually a WPF shortcoming, but my MVVM framework fixes it) 2) no clean way to 2-way bind to the selected item in a tree control (another WPF shortcoming) 3) no built in light weight DI container 4) no clean way to bind to item right clicks for context menus (without retemplating the item) 5) no way to bind to a password box 6) no single instance only support 7) no way to close a dialog or window from the VM 8) no way to disable the close on a dialog or window 9) no way to remove the window icon 10) no template-able task dialog Thats just from a quick scan of my code base :). Don't get me wrong... sometimes I grab code as a foundation and build upon it... but in this case, I looked at the various code bases and decided I would start from a clean slate.
1. Fair enough 2. Hoo yes 3. Not strictly speaking, necessary for a MVVM framework (but you can do this with Cinch 2 - uses MefedMVVM) 4. Yup 5. Been there, seen it, got that t-shirt. In fact, I once blogged about this very issue. 6. Cinch 2 - via MEF 7. Cinch 2 - via MEF 8. Nope, but could be done with Cinch 2 9. Not really MVVM related. 10. Again, not MVVM - but I can see why you'd want it.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
This is not really a question... When working with WPF trying to implement the MVVM pattern, I feel like I spend all of my time writing code to jump through hoops so as to not violate the MVVM pattern's principles... :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
I hear you. I started using MVVM without any framework and found I could get 90% of my code working that way. Reminded me of when I moved from C to C++ eons ago - the whole object oriented thing made no sense to me at first - now it's second nature. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
1. Fair enough 2. Hoo yes 3. Not strictly speaking, necessary for a MVVM framework (but you can do this with Cinch 2 - uses MefedMVVM) 4. Yup 5. Been there, seen it, got that t-shirt. In fact, I once blogged about this very issue. 6. Cinch 2 - via MEF 7. Cinch 2 - via MEF 8. Nope, but could be done with Cinch 2 9. Not really MVVM related. 10. Again, not MVVM - but I can see why you'd want it.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
9 & 10... yeah, not MVVM related in the sense of being part of the MVVM pattern, but its something that I needed to do and couldn't with any framework. Typically, dialogs that do not appear in the task bar are not supposed to have icons.
-
I feel the same way. It seems as though most of my time is spent on the architecture and implementing the pattern correctly. Then the actual core functionality of the application. But then again once all that is set up. Your life is made easier with unit testing etc.
Thats one of the main benefits. MVVM sort of makes you write really clean code by its nature. We've all written initialization functions that populate every control on the dialog in a single function whether they are shown or not. MVVM makes you populate the controls via very specific properties and makes you support lazy initialization. It also promotes seperation of controls code. I.e. lets say your dialog had 10 controls on it... we've all written MFC & Winforms code where IsEnabled & content properties are updated in 10 different places. MVVM makes you do it in a way that its all seperate and each control really only cares about itself. The other big benefit of course is that it moves a ton of code to the XAML.
-
No problem. I've written a couple of MVVM frameworks so I know the pain you've been going through. Had there been a mature, stable framework around when I first started, I wouldn't have bothered as I'm not a fan of reinventing the wheel.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Pete, I've started using MVVM Light. I'm slowly pulling pieces of it into my implementation. For example, I had written my own ViewModelBase class that encapsulates (is that the right word?) some common things that I needed for all of my classes. I changed the name of my base class and am now deriving it from Laurent's ViewModelBase, with all of my View Model classes still being derived from my modified base class. I was able to pull out some of the INPC stuff, etc. from my base class, and just use the MVVM Light implementation. Likewise, I threw away my homegrown (based on some of your code in fact) RelayCommand class and am using the MVVM Light version. There was nothing wrong with the homegrown version, but Laurent's is a bit more flexible. The Messenger class is the cat's a$$. I've found some good uses for that. I have not used the ViewModelLocator because I already had a scheme going that I like that was suggested to me by Collin Jasnoch, and it seems to be working well. All in all, I feel I am getting there. Thanks for the suggestions and encouragement. :thumbsup:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Pete, I've started using MVVM Light. I'm slowly pulling pieces of it into my implementation. For example, I had written my own ViewModelBase class that encapsulates (is that the right word?) some common things that I needed for all of my classes. I changed the name of my base class and am now deriving it from Laurent's ViewModelBase, with all of my View Model classes still being derived from my modified base class. I was able to pull out some of the INPC stuff, etc. from my base class, and just use the MVVM Light implementation. Likewise, I threw away my homegrown (based on some of your code in fact) RelayCommand class and am using the MVVM Light version. There was nothing wrong with the homegrown version, but Laurent's is a bit more flexible. The Messenger class is the cat's a$$. I've found some good uses for that. I have not used the ViewModelLocator because I already had a scheme going that I like that was suggested to me by Collin Jasnoch, and it seems to be working well. All in all, I feel I am getting there. Thanks for the suggestions and encouragement. :thumbsup:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Tom, I'm delighted that I was able to help here. Laurent has done a fantastic job with MVVM Light, and it is a good one to get up to speed with. Good job.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Tom, I'm delighted that I was able to help here. Laurent has done a fantastic job with MVVM Light, and it is a good one to get up to speed with. Good job.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Now if I could just get so that all of the views that I have designed weren't ugly... But that's another whole issue. :-D
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Pete, I've started using MVVM Light. I'm slowly pulling pieces of it into my implementation. For example, I had written my own ViewModelBase class that encapsulates (is that the right word?) some common things that I needed for all of my classes. I changed the name of my base class and am now deriving it from Laurent's ViewModelBase, with all of my View Model classes still being derived from my modified base class. I was able to pull out some of the INPC stuff, etc. from my base class, and just use the MVVM Light implementation. Likewise, I threw away my homegrown (based on some of your code in fact) RelayCommand class and am using the MVVM Light version. There was nothing wrong with the homegrown version, but Laurent's is a bit more flexible. The Messenger class is the cat's a$$. I've found some good uses for that. I have not used the ViewModelLocator because I already had a scheme going that I like that was suggested to me by Collin Jasnoch, and it seems to be working well. All in all, I feel I am getting there. Thanks for the suggestions and encouragement. :thumbsup:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Personally, I prefer using the ViewModelLocator method vs. DataTemplates. Some people are the other way around. I think the ViewModelLocator method is a lot cleaner and makes more sense. You load up a view and it should know how to do its own thing. Creating the VM first seems backwards to me. IMO, you shouldn't be creating VMs by hand. You should leave that to the view locator and DI. Also, the ViewModelLocator is 1 line in XAML vs. the DataTemplate method with is 3 lines of XAML + C# code to create the VM and set the DataContext.
-
Personally, I prefer using the ViewModelLocator method vs. DataTemplates. Some people are the other way around. I think the ViewModelLocator method is a lot cleaner and makes more sense. You load up a view and it should know how to do its own thing. Creating the VM first seems backwards to me. IMO, you shouldn't be creating VMs by hand. You should leave that to the view locator and DI. Also, the ViewModelLocator is 1 line in XAML vs. the DataTemplate method with is 3 lines of XAML + C# code to create the VM and set the DataContext.
I'll take your suggestions under advisement. For now, however, I'm going to leave that part of things alone. For this particular app, it is working well, and I have changed enough things around already. Maybe my next project. I need to get moving on this thing and get it finished up! ;) Thanks for the suggestions. I appreciate the input. :thumbsup:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
This is not really a question... When working with WPF trying to implement the MVVM pattern, I feel like I spend all of my time writing code to jump through hoops so as to not violate the MVVM pattern's principles... :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
I felt the same way when I first started MVVM, then I stepped back and reconsidered what the puropose of MVVM really is...To segregate your data and business layers from the UI. Read through this little example and you'll see my point at the end. Take for example double-clicking a list item. You want to know in the ViewModel what list item was double-clicked. You can bind the list's SelectedItem in the XAML to a property on the VM, but that handles clicking a list item, not double-clicking. To handle this, you need to handle the event. But that's not easy in MVVM. Here's what I do to handle something like this. In the View's code behind: First the XAML
Then in the code behind:
public MainPage()
{
InitializeComponent();
this.DataContext = new MainPageViewModel();
}then the event
private void ListBox_MouseDoubleClick(object sender, MouseButtonEventArgs e)
{
ListBox list = sender as ListBox;
ListItem item = list.SelectedItem as MyBoundType;var dc = this.DataContext; dc.ListItemDoubleClicked(item);}
This assumes a method in your VM called ListItemDoubleClicked that accepts a parameter of the type bound to your list. The point here is this - you can write code in your views that references your VM becuase the view already knows aout the VM. Just don't write any data-related code in the view's code behind and you're not violating VMMV.
Everything makes sense in someone's mind
-
I wrote my own MVVM framework probably 6 to 8 months ago. There were 10 to 12 open source ones available. I chose to reinvent (and improve) the wheel. 1) I didn't want the code cluster f*cked up with Silverlight (and other nonsense) support since I have no interest in that and it's a dead platform anyways 2) No MVVM framework out there provided 100% of the plumbing needed to write a full blown MVVM application. 50%? Absolutely. 75%? Probably. 90%+, sorry, but no. You'd have to combine 3 or 4 open source projects to get to where I'm at I think. Now granted, I may not have all the features of those 3 or 4 projects combined, but I have what is needed to write a full blown MVVM application and they don't. For example, none of them have a way of binding to multiple selection tree / list controls which I found to be quite important :).
Looking forward to your CP article on your framework :) best, Bill
"Science is facts; just as houses are made of stones: so, is science made of facts. But, a pile of stones is not a house, and a collection of facts is not, necessarily, science." Henri Poincare