Making the move to MVVM

[Solarion]

Making the move to WPF [MVVM]

I'm thinking this might be a good career move. I have to do something to keep up. Any suggestions?

I found this, probably the best article I could find.

https://www.codeproject.com/articles/173618/mvvm-sharp-episode-1

 

[Solarion]

 

[gkm]

Are you asking if WPF skills is a good career more or if MVVM is a valid pattern for WPF applications? Guess the answer to both can be yes, depending on your situation.

 

[^^vampire^^]

I don't see many people specialising in WPF and I don't see many jobs ever listed for primarily a WPF developer. In my experience not many people use it, however that's just from what I have seen in my own experience. There are occasionally job ads wanting WPF and I am of the idea that if a job wants it then it is always something you can learn.

MVVM, however, as a pattern is useful to know and you will find it coming up everywhere, especially when you work more with the js frameworks and/or libraries. At the end of the day the more you know the more employable you are, especially when these are becoming more mainstream.

 

[Hamster]

^ WPF job market

 

[XennoX]

It seems you are conflating the idea of MVVM and the idea of development. As a developer, you are expected to know which tool to use for which job. MVVM is just one of several design patterns out there, and thus it will only get you so far.

There is an idiom that I keep hearing, "Just because you have a hammer, does not mean all problems are nails."

 

[Batista]

I dislike MVVM, I think it only works in the case of very large apps that are worked on by multiple people, otherwise for simple apps its way overkill!

 

[Solarion]

Appreciate the feedback from all of you. I was just throwing the idea out there. I do prefer WinForm development and a lot of the advice from guys like Roi, spacerat etc have been incredibly helpful.

The more I am learning about MVVM the more I am learning it is not what I thought it was and is way over hyped and too far removed from where I am at the moment and how far I have come recently. I am busy wetting my toes in the Dependency Injection and layered application environment and I would like to stay with that.

 

[Spacerat]

I dislike MVVM, I think it only works in the case of very large apps that are worked on by multiple people, otherwise for simple apps its way overkill!

Sorry, but that is wrong...
You can use MVVM even for one-form app (not talking about a hacked-together app to test something else). MVVM is not complex.
Lots of benefits of separating presentation and behaviour. Why , in your mind is it only suitable for large apps? [genuine question]. Hell, I use it on mobile apps running on WinCE. It allows me to develop and fully debug on the PC. Then just hook up a WinCE specific form to the ViewModel and viola. I think you prob have not used MVVM enough to realise the potential.

EDIT:

If you do WinForms dev, read my post on databinding for WinForms. See the power of databinding. Seems few ppl use it. That forms the start of getting into MVVM

I will follow that up with how to get the control click event handlers into the ViewModel

 

[Spacerat]

Appreciate the feedback from all of you. I was just throwing the idea out there. I do prefer WinForm development and a lot of the advice from guys like Roi, spacerat etc have been incredibly helpful.

The more I am learning about MVVM the more I am learning it is not what I thought it was and is way over hyped and too far removed from where I am at the moment and how far I have come recently. I am busy wetting my toes in the Dependency Injection and layered application environment and I would like to stay with that.

Go to the Syncfusion website. They have LOADs of free ebooks. https://www.syncfusion.com/resources/techportal/ebooks

One of them is on SOLID. Have not read it yet, but give it a try.

 

[Solarion]

Go to the Syncfusion website. They have LOADs of free ebooks. https://www.syncfusion.com/resources/techportal/ebooks

One of them is on SOLID. Have not read it yet, but give it a try.

Awesome, thanks!

 

[[)roi(]]

Appreciate the feedback from all of you. I was just throwing the idea out there. I do prefer WinForm development and a lot of the advice from guys like Roi, spacerat etc have been incredibly helpful.

The more I am learning about MVVM the more I am learning it is not what I thought it was and is way over hyped and too far removed from where I am at the moment and how far I have come recently. I am busy wetting my toes in the Dependency Injection and layered application environment and I would like to stay with that.

A good way to make this a little less abstract is to write an app; ideally one that includes some:

1. Interaction with an API and/or database
2. Custom user interface
3. Local data computation
4. optionally API and/or database update.

As for MVVM; it's by no measure the only way to build apps, nor is it the only way to build structurally sound ones. There are many different approaches, each having Pros/Cons.

Nevertheless you have to start somewhere and either MVVM or MVC is good starting point.

 

[[)roi(]]

Sorry, but that is wrong...
You can use MVVM even for one-form app (not talking about a hacked-together app to test something else). MVVM is not complex.

Disadvantages? For simple UI, M-V-VM can be overkill. In bigger cases, it can be hard to design the ViewModel up front in order to get the right amount of generality. Data-binding for all its wonders is declarative and harder to debug than nice imperative stuff where you just set breakpoints (though if you have lots of events running around, it may not be much different).

https://blogs.msdn.microsoft.com/johngossman/2006/03/04/advantages-and-disadvantages-of-m-v-vm/

 

[DA-LION-619]

https://blogs.msdn.microsoft.com/johngossman/2006/03/04/advantages-and-disadvantages-of-m-v-vm/

I would say in the beginning it's daunting but after you get the hang of it, you don't really find an issue implementing it.

I started with Windows Phone Silverlight, after I got the hang of it. Seeing code behind made me sick.

 

[[)roi(]]

I would say in the beginning it's daunting but after you get the hang of it, you don't really find an issue implementing it.

I started with Windows Phone Silverlight, after I got the hang of it. Seeing code behind made me sick.

My reply was in response to @spacerat arguing against @Batista's view that MVVM is an "overkill" for "simple apps". i.e. John Gossman; the creator of MVVM also said exactly that.

For simple UI, M-V-VM can be overkill.

Personally I don't use MVVM at all; but that stems largely from a difference in paradigm. Plus with complexity even with MVVM, a rigid approach is never advised; meaning IMO it's quite acceptable to e.g. spin off more controllers -> MV[C..C]VM

 

[Solarion]

A good way to make this a little less abstract is to write an app; ideally one that includes some:

1. Interaction with an API and/or database
2. Custom user interface
3. Local data computation
4. optionally API and/or database update.

As for MVVM; it's by no measure the only way to build apps, nor is it the only way to build structurally sound ones. There are many different approaches, each having Pros/Cons.

Nevertheless you have to start somewhere and either MVVM or MVC is good starting point.

I'm working on it. I have a small Job Card management app. It has a UI, BAL and a DAL. I've used Dependency Injection to separate the layers. As I am going along at the moment am still going back to all the examples you, spacerat and others were so incredibly helpful with. It's a work in progress.

At the moment I at working on Databinding. Something got me set off on this WPF/MVVM stupidity I'm not sure what but I've scrapped it.

Edit: MVC huh? You think I should learn that?

 

[[)roi(]]

I'm working on it. I have a small Job Card management app. It has a UI, BAL and a DAL. I've used Dependency Injection to separate the layers. As I am going along at the moment am still going back to all the examples you, spacerat and others were so incredibly helpful with. It's a work in progress.

At the moment I at working on Databinding. Something got me set off on this WPF/MVVM stupidity I'm not sure what but I've scrapped it.

Edit: MVC huh? You think I should learn that?

Lol... no rather stick with your goal. Focus on making your app work; then as a second, third, ... step -- look at how you can improve it. Plus at that stage your questions are likely to be problem specific; e.g.

• how do I prevent the UI from ...?
• Is there a better way to do ...?

As for MVC (Model-View-Controller); it's just an alternative to MVVM (Model-View-ViewModel). MVC, for your information, tends to be the de facto approach for iOS, macOS and quite a bit of web development; most likely because a lot of their underlying frameworks were designed around this pattern; however that doesn't mean you can't use MVVM -- you certainly can, and so too many other design patterns. In a way it's a personal choice.

 

[Solarion]

Lol... no rather stick with your goal. Focus on making your app work; then as a second, third, ... step -- look at how you can improve it. Plus at that stage your questions are likely to be problem specific; e.g.

• how do I prevent the UI from ...?
• Is there a better way to do ...?

As for MVC (Model-View-Controller); it's just an alternative to MVVM (Model-View-ViewModel). MVC, for your information, tends to be the de facto approach for iOS, macOS and quite a bit of web development; most likely because a lot of their underlying frameworks were designed around this pattern; however that doesn't mean you can't use MVVM -- you certainly can, and so too many other design patterns. In a way it's a personal choice.

Wish I had read this even a week ago, it would have saved me this little tangent I went on. That is some excellent advice. To build a project model that I am happy with and to slowly add to it new skills I pick up. At some point I will take a look at other things perhaps MVC, most likely. For now I think I will leave such things for the time being and just focus on things like Generics, Delegates, Lambda's etc and digging into this DI book I have.

Basically all the really necessary, core stuff.

 

[Hamster]

Edit: MVC huh? You think I should learn that?

Yes, even if it's just for 80% of the interviews you'll be going to in the coming years.

 

[Spacerat]

As for MVVM; it's by no measure the only way to build apps, nor is it the only way to build structurally sound ones. There are many different approaches, each having Pros/Cons.

Agreed. But having code behind the form is just terrible. Unfortunately that is how WinForms/C# programming is taught. And I understand why. But it sticks and most devs never move on to use a proper pattern.

My reply was in response to @spacerat arguing against @Batista's view that MVVM is an "overkill" for "simple apps". i.e. John Gossman; the creator of MVVM also said exactly that.


Personally I don't use MVVM at all; but that stems largely from a difference in paradigm. Plus with complexity even with MVVM, a rigid approach is never advised; meaning IMO it's quite acceptable to e.g. spin off more controllers -> MV[C..C]VM

Don't agree with Gossman. But that's just me.

MVVM is not complex. If you have an MVVM framework that works, it becomes 2nd nature to use it and think along this pattern. MVVM makes lots of things much simpler. Simpler and less code. The less code the better. MVVM (or MVC) also lets you run automated tests against the VM/C to verify UX behaviour & state. Not so with the code-behind mess.

With MVVM your design starts off with the desired UX. IMO that is far better than to slap controls onto a form and click-click eventhandlers. The VM (or Controller) also provides the separation between the view and whatever happens in the back-end. Many devs just slap that into the event handlers in the code-behind. Ugh...