Has anyone used MVVM?
-
In all but the simplest of designs it creates more trouble than it is worth. Which is odd considering your question. Most places that require it's use are not using it for what it is designed for. MVVM works great with WPF primarily because it lets you abstract the programmer from the designer. However, every place that uses it relies on the programmer to do the UI as well as the rest, negating it as a valid tool. Data binding, as the auto magic amalgamation that it is, causing more problems than it is worth. Btw, before you argue: Write a WPF app using MVVM that displays the data in a tree, allows drag and drop between trees and allows each tree to contain multiple sources and types of data. The point is not that it can be done but why bother when other tools are better suited to the job. Furthermore, and this is the really important thing to consider when using MVC (different I know), almost anything can be MVC and just like with MVVM you will spend half of your time arguing with people who think what you have done isn't MVC or MVVM because it doesn't match the sample from Microsoft that is so naively simple as to be worthless.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Nobody uses the MVVM acronym any more, it is soooo last year. To be considered really 'with it' in computing circles you should refer to it as 'The Tommy Cooper Design Pattern'!
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” Why do programmers often confuse Halloween and Christmas? - Because 31 Oct = 25 Dec. Business Myths of the Geek #4 'What you think matters.'
I've used MMIX, but that was last year too!
-
Glosse wrote:
Or does it grossly complicate what otherwise would be a simple program?
Almost every design pattern does that. :-\ But then.....MVVM does have its advantages and is useful when you want to decouple your data placeholders from the view.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it. My latest tip/trick - Silverlight *.XCP files
-
Do you find it useful? Or does it grossly complicate what otherwise would be a simple program?
Have been using MVVM for production for a few months now and I love it! There are some little quirks that you run up against when you start out though that would normally be handled in code behind, like double-clicks and dragging, but there are some creative solutions to those if you search online. We do actually have a designer though (not a coder doing design, but an actual designer), so I think we see more benefit than those without. All said and done, the WPF binding system is a magical beast that is fun to abuse. As for adding complexity, the answer is yes and no. In my mind, it is only initially adding complexity as we go through a learning curve. We are starting to just roll past those initial issues though and it is deffinately making life easier.
"It's like the sixties, but with less hope."
-
Glosse wrote:
Do you find it useful?
I used this with WPF when writin a customer relationship management system for bank, it was a very good fit.
Glosse wrote:
Or does it grossly complicate what otherwise would be a simple program?
It worked out well in my experience, but it does need a proper object model (and a lot of systems are really just glorified database front-ends - though I avoid writing systems this way) and you do need to separate the concerns out properly . The MVVM sent testability through the roof , as the view is isolated, and you can run unit tests against the viewmodel and model (at least in WPF you can). I don't know how well it would apply to winforms or webforms though I've seen articles around and it looked pretty clean, so YMMV. Pete o'Hanlon (a regular here) has a framework he was working on, he might have a better insight than me. [edit:- he replied while I typed this!]
ragnaroknrol The Internet is For Porn[^]
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.YMVVMMV?
-
Do you find it useful? Or does it grossly complicate what otherwise would be a simple program?
I just stumble upon this blog post about MVVM, you may find it useful: http://davybrion.com/blog/2010/07/the-mvvm-pattern-is-highly-overrated/[^]
-
Do you find it useful? Or does it grossly complicate what otherwise would be a simple program?
I think to really appreciate MVVM (or MVP), try solving the problem yourself without using a rule book of pattens. Next time you write some UI, try to eliminate as much code in the UI layer as possible, and put all that logic in a middle layer called a presenter. Make sure the "presenter" knows nothing about UI. In fact, you might want to write a command line interface to your program which also uses the presenter to do the work. That will really drive home the point that the presenter is about the logic. After you're done, take a look at the view layer again. If this is a WinForms app, look at the code inside the forms, and really ask yourself how much of that is really related to that particular view, or can the code be reused by other views or clients. When the presenter needs to talk to its client (i.e. the view, or the command line program), have it talk to it via a site interface -- call it IClient or something similar. Once you get it to this point, you'll realize how little you actually have to have in the view. And you'll notice how much of it you've actually been able to unit test through the presenter. If the presenter is 99% of the code, then you have access to that much code through your unit test, without using any kind of "test through UI" tools. Once you've done that, take a look at Fowler's MVP pattern, and really understand the details of what he's talking about. You'll see that the pattern is a generic way of solving the same problem you just solved. MVP is a pattern, with no support from the tools or language. MVVM can be thought of as an implementation of MVP because the data-binding facilities of WPF are so powerful, you can do (almost) all of the work without writing any view code at all. The goal shouldn't be 0% view code, but you'll find that you'll achieve that many times. Of course, there's nothing wrong with code in the view if that code really is about *that* view. Good luck.
-
I just stumble upon this blog post about MVVM, you may find it useful: http://davybrion.com/blog/2010/07/the-mvvm-pattern-is-highly-overrated/[^]
Actually, this is probably the worst post you could link to. It's a very high level esoteric discussion of the topic, and there's a fundamental dispute going on over there about how MVVM differs from MVP (or more practically, MVPP which the author doesn't seem to be aware of). A better POV is laid out in my mucker Jeremiah Morrill's excellent blog post here[^]. He helps to lay out the myths around MVVM and shows how it can be best approached.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Do you have an article or anything you can share about it? I'm interested in it.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
Yeah, Check my book mark page, Barbber has many articles on it
"Make everything as simple as possible, but not simpler." -- Albert Einstein "It didn't matter to us whether people believed in us. We believed in ourselves. We had the courage to follow our own path." ~~Nvidia's Jen-Hsun Huang
-
Actually, this is probably the worst post you could link to. It's a very high level esoteric discussion of the topic, and there's a fundamental dispute going on over there about how MVVM differs from MVP (or more practically, MVPP which the author doesn't seem to be aware of). A better POV is laid out in my mucker Jeremiah Morrill's excellent blog post here[^]. He helps to lay out the myths around MVVM and shows how it can be best approached.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Pete O'Hanlon wrote:
Actually, this is probably the worst post you could link to.
Ouch!, ok, no offense taken. I wouldn't discuss with you about wpf/silverlight here because obviously you've more miles than me, so, I respect your opinion. Like most people, I'm trying to grasp this new way of do things (I've a web development background), I've tried PRISM and now I'm giving a try to nRoute, the problem is that I'm using it on pet projects of mine, and in my experience that's not enough, you need a real project with real requirements to fully understand what its all about. Ok, back to MVVM, no doubts is a great pattern, but I think most people assume you've great xaml skills and they skip some not so obvious subjects and that makes thing even more difficult to understand. However, I reckon that nobody out there owes us any kind of free training. I'll check out the blog post that you are referring to, thanks for sharing it.