WPF Discussion Boards

Glosse18-Aug-11 7:34

18-Aug-11 7:34

I stand abashed. MVM was devised by people far smarter than me. However, coding trends come and go.

It would be interesting to do a survey to see how many are actually using the MVVM pattern, or are planning to use it. MVM seems to fly in the face of the KISS principle.

As a consultant, bidding and developing LOB apps is very competitive. Time is money. Code should be concise and logically structured. It should be easily picked up and modified at a later date.

What are the benefits? You say it is elegant. You say once you get used to it its easy. In the middle ages wearing a hair shirt or self flagelation were thought to bring you closer to God.

Re: Need some Simple Code

SledgeHammer0118-Aug-11 9:32

SledgeHammer01

18-Aug-11 9:32

Well, sometimes I find people who over complicate stuff for no reason to be a bit pretentious and they are just trying to impress themselves. In the case of MVVM however, its just simply a better way to write WPF code. When I first saw it, I thought like you: "geez, this is stupid... its making things more complicated", but once I got used to it, I saw *WHY* its good.

For example, lets say you implement a dialog box that has a few buttons and a ListView, chances are you populate most if not all of the data in the constructor, manually insert stuff into the ListView, subscribe to lots of events, have a lot of duplicate code and tie all of the dialogs logic closely to the ListView. Now lets say your boss is a douche and comes to you in a month and says "I don't like the ListView, lets change it to a WidgetView". Well, now you pretty much need to re-write and re-test all your dialog code. Sux 2 b U. If you had written it in the MVVM style, you would have been able to swap out the ListView for a WidgetView in about 5 minutes and not have to re-write or re-test anything. You'd also have a lot less code, your dialog would come up faster because you would be lazy loading all your data (one of the things that MVVM kind of pushes indirectly) and you could write automated tests for your dialog box if thats something your company does.

Yes... its much easier to quickly whip out:

somecontrol.SomeEvent += <tab><tab>

vs. creating a RelayCommand and implementing its 2 event handlers, but you can pretty much write a macro for that in about 2 seconds. Theres already a built in macro for defining dependency properties, so adding one for the RelayCommand is just c&p pretty much.

The code does end up being more elegant, but the advantage for me is that I don't have to keep changing the dialog box code until the boss is happy with it, I just tweak some xaml.

Re: Need some Simple Code

_Maxxx_18-Aug-11 13:41

_Maxxx_

18-Aug-11 13:41

Glosse wrote:
MVM seems to fly in the face of the KISS principle.

The MVVM principal is actually reasonably simple. The problem, I think, with peple's taking up of it is that it isn't something you can just become an expert in in a couple of days - you need to have the time to play with it and get to know your way around - and decide how YOU want to do it.
It took me a few months from first reading about it to actually having something I felt comfortable enough to use in the real world. I still don't use it enough to make is second nature (because i can't use it in my current day job) but if I was starting a new project, and could, I would certainly use it.

Glosse wrote:
MVM seems to fly in the face of the KISS principle.

There are a lot of articles out there showing people how to overcome difficulties using MVVM, or how to achieve something using MVVM that, I think, make it look far more complex than it is in fact.

many people misunderstand MVVM (the 'there must be not code behind' ers being a majority group!) Again, once you have been using it for a while, you start thinking about projects differently and it becomes 2nd nature.

Glosse wrote:
What are the benefits?

In my experience, especially as a consultant, the user is never, ever, happy with the project they receive. it can do all the clever things that they never even thought of, technically it can be doing something in milliseconds that other systems take many seconds to do, and can have a small memory footprint, be self updating and extensible - but the customer doesn't like that shade of green, would like the fonts bigger, hates check boxes and wants radio buttons, and so on.

Designed with MVVM, the presentation can be changed, leaving the functionality alone. The application still does just what it used to , but now looks different.

Indeed, with the right set up, you can display design time data, and sit with the user to show them as you develop, without writing code (or, at least, not much)

Glosse wrote:
In the middle ages wearing a hair shirt or self flagelation were thought to bring you closer to God.

I appreciate what you are saying - are the MVVM evangelists just that - evangelists who have faith and want to spread the word? Do they just 'believe'.

I can't speak for others, but my experience was to start with thinking "so what's so great about this MVVM thing" and start playing. I then went through the "well, this is crap, I can't even show a dialog box without thirty pages of code" stage. I nearly gave it up at that point, and had a few discussions with people (P. O'H being a great help) to get my head around what MVVM actually meant

I then went through the "looking at every framework" stage - and realised (again) that I hate frameworks because people try to make them do lots of stuff that then constrain me - so I went onto the "how should it really be" stage.

That's when I sat back and started work on my articles - not for CP but for me - putting stuff down in writing, having a toy application to start developing really helped me get my head around many aspects of MVVM, helped me develop my own version of a framework, that I could use simply elsewhere.

And, despite giving up and starting again many times whiole writing the articles, moving onto other projects (some using MVVM some not) I kept coming back to MVVM.

when working on non MVVM projects, I kept wishing it was MVVM as it would make things easier

So, it took me a lot of time and effort, and I've been programming for 35 years, so it was very much 'old dog, new tricks', but when I came out the end of the tunnel, I felt there was no going back.

To those at the other end of the tunnel, well, you're doing fine where you are, have fun and be happy. The tunnel is ling, often dark, and has some dead ends along the way, but if you do get through it, you'll see that there are no hairy shirts or self-whacking folks

MVVM# - See how I did MVVM my way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011

.\\axxx
(That's an 'M')

Re: Need some Simple Code

Mycroft Holmes18-Aug-11 14:54

Mycroft Holmes

18-Aug-11 14:54

I went through almost the exact same cycle except there was never a small app to say this was too complex for. I needed to drag an entire team into a proper WCF based design platform from many years of winforms development. I was refactoring some code last week and had to do the face palm, what was I thinking, no doubt I will do the same in a few more months as my understanding deepens.

My biggest bitch at the moment is that Oracle is case sensitive and insists all objects be named in uppercase, this totally f***s up my ORM code generator. I have almost identical systems in both Oracle and SQL Server and I have to write 2 distinct apps (that almost is a killer), either that or hand code all the table/field names in the ORM.

Never underestimate the power of human stupidity
RAH

Re: Need some Simple Code

_Maxxx_18-Aug-11 16:01

_Maxxx_

18-Aug-11 16:01

ORM? pah - that's for sissys! Type until your fingers bleed!

I'd have thought your solution would be to uppercase everywhere?

You CAN make SQL server case sensitive too, if you want.

MVVM# - See how I did MVVM my way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011

.\\axxx
(That's an 'M')

Re: Need some Simple Code

SledgeHammer0118-Aug-11 18:47

SledgeHammer01

18-Aug-11 18:47

_Maxxx_ wrote:
many people misunderstand MVVM (the 'there must be not code behind' ers being a
majority group!)

There really doesn't need to be in most cases. Most of the time I have seen code behind, its been that the developer was lazy and didn't have a strong enough framework. I just wrapped up an MVVM project and didn't have *ANY* code behind. I mean ZERO. All windows, dialogs, controls, etc. had the code behind .cs DELETED. Not even a call to InitializeComponent() Smile | :)

. I have a generic event -> command mapper in my framework, so I just use that in the XAML and I pretty much end up with as much code as I would if I would have done the code behind -- except I don't have code behind. I know its not a requirement of MVVM, but I just don't like it. It makes me feel like I'm splitting a class between 2 .cs files and I'm going to use up a lot of my time deciding if a method should go in the VM or in the code behind.

Now, I realize that if you need code to manipulate the visuals, it shouldn't go in the VM... but thats just another case of the developer being lazy. If you *really* need code to manipulate visuals, you should make it a generic / reusable control, not part of the view.

Re: Need some Simple Code

Abhinav S19-Aug-11 1:47

Abhinav S

19-Aug-11 1:47

I found this [^]to be a good read.

Too much of heaven can bring you underground
Heaven can always turn around
Too much of heaven, our life is all hell bound
Heaven, the kill that makes no sound