Following all the helpful advice re my journey (as they say these days) from the safe (albeit peculiarly non-standard) realm of Delphi to the brave new world of Dot Net, WPF and now (scary …) MVVM, I have just spent the last hours looking at MVVM examples. Whilst recognising the advantages of the formalisation, separation of UI and logic, etc. that this gives - particularly in major development environments with teams of developers, probably spread out geographically as well as functionally, I still wonder whether it is a bit of overkill for the single person Windows desktop developers like me.
A lot is talked about the enhanced robustness of the above approaches in terms of code maintenance, ability to change UI without damaging logic, etc, etc. and I accept all this. But for the single person developer, where looking back at code that you did 6 weeks ago requires a major exercise in analysis, it is perhaps less relevant (or is it more relevant?)
My mind goes back to the halcyon days of Z80 programming in hex (assembler - couldn’t afford that!)
So Hex Code 77, (Load HL Immediate) became embedded in my memory!
Perhaps what we need today is a RemObjects DotNet for dummies (i.e. for the over 70s like me)
Although the above is light hearted (in the main!), I would love to see what “programming” looked like in 20 years time, and more amusingly, what “programmers” of that time felt about today.
Finally to you MVVM enthusiasts - do I really need it for my Login Screen?
WPF has a very strong learning curve, most will say its the way to go due to separation of concerns etc, and indeed, i will say its fine. BUT, at least on my company, everyone feels that everything is a bit complex (overkill) and probably will not support it in the future moving to some web technologies.
The issue is that only two or three guys became and stayed fluent at it (WPF), the rest struggle, so as a result, any small change we always ended up booking a lot of time to have things done.
Some (including myself) ended up just cleaning up our Delphi code, adding some needed dependency injection, interfaces and less components to our lives creating a better separation of code and implementing the utils we needed on VCL/FMX.
Oxygene is great and has nothing to do with it. It just one more shot fired by MS on another potential Silverlight.
Just leaving WPF and MVVM for this discussion and get it a liitle simpler: UI and functional code separation.
Because WPF and MVVM are methods for it.
I started programming in the 80ties and yes also on the Z80. Programming this hex-codes was fun at the time. And I also work alone.
About 15 years ago a began to implement my code as layers; database layer, functional layer, UI code layer, UI layer - I did not follow any specific model for this, but tried to separate the layers as much as possible.
And what I learned from this: It really works; I have now a lot of reusable code; the database layer and lots of the functional layers are in all my applications. But because I still only do Winforms, the separation of the UI did not bring me much; I never had 2 or more UI’s for my application (you will if you are going to do multi platform or mobile development).
And yes, starting to use isolated levels of code is not easy, but it pays of; you will get your own reusable code and yes it gets a lot more maintainable.
If you need “For Dummies”, then don’t use WPF, but go for WinForms.
And as I said: build your own layers (dll’s) - methods as MVVM are nice but not for me as a programming dinosaur .
For simple apps? You really don’t need it for your login screen no.
However MVVM has a lot of advantages, even in simple applications, mainly because things rarely stay all that simple. An example, a simple Todo application.
It starts with a list of tasks with a certain date, [done] checkbox, and description.
Then in a while, you think, this would look nice in a calendar view too, so you add that.
Now you have two things that work on the same data. In lets call it “classic winforms/delphi events”, you’d have two copies of the “delete task”, and “update task” logic.
The next feature would be to email if a certain task gets closed, and it has to be placed in both places.
So really, sure, a simple app doesn’t really need MVVM, but no app stays very simple. It doesn’t have to be MVVM but the nice thing about MVVM is that it forces you to separate things logically.
In the todo application like above, you’d have a Model with a list of tasks and everything related to the data.
You’d have a view model that deals with getting the tasks in a specific order, creating new tasks, deleting tasks, closing tasks. And you’d have two views, 1 is a simple list of tasks, the other a calendar.
A criticism of the pattern comes from MVVM creator John Gossman himself,[12] who points out overhead in implementing MVVM is “overkill” for simple UI operations. He states for larger applications, generalizing the ViewModel becomes more difficult. Moreover, he illustrates data binding in very large applications can result in considerable memory consumption.
So I guess this means there is a “Goldilocks” zone in which the size/complexity of a UI app is “Just Right” for MVVM. Smaller/Simpler than that and it’s overkill and larger/more complex than that and it becomes unwieldy.
The same/similar has sometimes been said of WPF in general, it must be noted.
Many/most techniques that are useful for teams are also useful for single devs (or single-dev projects).
Take version control for example. For the longest time, the general assumption was that you’d only need it for team work. But I cannot imagine not having version control for any code I work on, these days. (as the saying goes — version control is like brushing your teeth. you don’t need to Bruch ALL of em, just the ones you want to keep. ;).
Think of techniques like this not just as making it easier for others to work with your code, but also for you to work with your code, 3 weeks down the road (because remember, this applies to developer: 3-weeks-ago-you was an idiot who didn’t know what he was doing and now you need to deal with the mess he made
.
