Making the move to MVVM

[[)roi(]]

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.

Not adopting MVVM doesn't imply this, but yes making code heavy views is a code smell, but no more than massive ViewModel and/or massive Controller.

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

No worries. Some even question SOLID., which is good because most of what is now accepted as good practice was discovered by someone who chose to not just fall in line and accept the standard of the day.

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...

It's an "Easy vs Simple" situation; that is, we shouldn't forget its always relative to an individual; as we know initially complex topics can become simple over time, however for a starting developer, almost everything is some degree of complex.

Hence I recommended he just focus on building the app; as its often easier to appreciate a fix after hitting an issue.

 

[Spacerat]

Not adopting MVVM doesn't imply this, but yes making code heavy views is a code smell, but no more than massive ViewModel and/or massive Controller.

Totally agree, if you have a complex ViewModel then you are likely violating SRP

No worries. Some even question SOLID., which is good because most of what is now accepted as good practice was discovered by someone who chose to not just fall in line and accept the standard of the day.

Yes I just think his arguments are weak and a small little para? Really...

It's good to continually question and evolve SW dev techniques. We are all striving for bug-free/high quality code that you can put out in the least amount of time. Personally, since having adopted SOLID and TDD, my code quality and throughput have sky-rocketed. TDD is a massive investment but that is another topic. Couldn't do it any other way. Wonder what the SOLID detractors' arguments are. You will always have ppl criticizing a particular technique. Like the Onion Architecture. Great concept with many haters. The challenge is sifting through the noise and BS and distill out of that something that you adopt. The really important part for a dev is to be aware of this continuous evolution and stay with it. Whether you adopt it or not is another matter.

It's an "Easy vs Simple" situation; that is, we shouldn't forget its always relative to an individual; as we know initially complex topics can become simple over time, however for a starting developer, almost everything is some degree of complex.

Hence I recommended he just focus on building the app; as its often easier to appreciate a fix after hitting an issue.

Agreed, especially for a junior dev, there is so much to learn. Unfortunately, if he is in the 'wrong' environment where senior devs have bad practices, he will adopt those and thus those will be perpetuated.

 

[[)roi(]]

Totally agree, if you have a complex ViewModel then you are likely violating SRP

Yip

Yes I just think his arguments are weak and a small little para? Really...

Uh huh, my sentiments exactly...

It's good to continually question and evolve SW dev techniques. We are all striving for bug-free/high quality code that you can put out in the least amount of time. Personally, since having adopted SOLID and TDD, my code quality and throughput have sky-rocketed. TDD is a massive investment but that is another topic. Couldn't do it any other way. Wonder what the SOLID detractors' arguments are. You will always have ppl criticizing a particular technique. Like the Onion Architecture. Great concept with many haters. The challenge is sifting through the noise and BS and distill out of that something that you adopt. The really important part for a dev is to be aware of this continuous evolution and stay with it. Whether you adopt it or not is another matter.

In a way you could say anyone who doesn't strictly follow the OOP paradigm is a SOLID detractor; but that's only true to a point.

Plus e.g. even Liskov stated that she never personally coined the phrase `Substitution Principle` and was surprised about the veracity of its adoption + quite a lot of the type stuff she felt was similarly important was all but ignored in the initial OOP / SOLID approach; the latter C# / F# years have however added some of that ito general FP extensions and generic typing, and even her more recent work in concurrency (Futures, Promises, Binding, ..) e.g. async, await, Linq parallel, etc...

Agreed, especially for a junior dev, there is so much to learn. Unfortunately, if he is in the 'wrong' environment where senior devs have bad practices, he will adopt those and thus those will be perpetuated.

Sure, but it's no absolute.