Some musings on MVVM

Elements Oxygene
1

Wow! After just an hour or two reading comments and descriptive instructions on this supposedly “heady” topic, I finally gave up and read the Wikipedia entry on MVVM. And though it was a little more straightforward about this particular methodology allowing me to correctly place its intrinsic differences amongst other model view structures I’ve dealt with over the years, it still amazed me at how cryptic and intentionally complicated their information seemed to be!

Einstein said, ( and this is by no means a direct quote ), there are two examples of the infinite. One being the Universe itself, and the other being mankind’s ability to be wrong. But he forgot to mention how often we destroy good, simple, information by our seemingly common need to overcomplicate and infuse with overly verbose descriptive analysies the teachings we wish to share with each other. And after reading about MVVM last night I have to say that even at the most basic level, this subject makes a great example of this trend to make simple ideas undecipherable!

Perhaps it’s our way of making ourselves appear to be smarter than we really are. But no matter the underlying reasons, we all need to stop talking and writing in riddles! MVVM isn’t rocket science! nor is it anything new, different, or particularly invaluable for what it is designed to accomplish. In fact, and in relation to many other similar systems used for improving OOP code through isolation, seperation, access and aquisition, it is comparatively simple! The ONLY reason it’s been promoted by Microsoft that I can see is that it is a valid…though not necessarily the best…choice for those programming via the XAML structure they are rightly promoting. They can’t even agree on any particular direction code, structure, and data should flow among the tertiary model MVVM describes! ( That being a good thing )

XAML doesn’t require a descriptive analysis to understand by any programmer experianced with OOP-ified coding practices. It’s self-descriptive and very easy to use for gui alterations applying simple cut and paste. And MVVM is just as simple in its own right. I’m a self-educated programmer who realized the design and implementation benefits of OOP programming and how simple forms of modeling and code seperation could increase productivity and security by the time I had written my second dB program with Delphi 1! And very soon after that I learned to extend these practices…especially as regards code-gui seperation in non-datacentric applications…because it also benefited me to call events via operative code rather than directly within events as most languages today make so dam easy.

Please don’t think I’m bragging or being presumptuous, as I really do see things this way. And a few of the comments I read in response to “Visual Studio” articles on the subject makes me believe I’m not the only one! There’s absolutly no excuse for their making simple concepts so difficult to grok through indescreet overanalysis and complication. It’s unfair to the novice programmer, and a waste of time for those of us already knowledgable in OOP basics! Nuff said!

2

Base technology for frameworks but not the sole purpose of WPF. WAF (http://waf.codeplex.com/) is a good candidate. There is a mismatch in reality. The design of an application should be independent from the implementation technology. It is somehow progress to be in the position to switch between different Microsoft front-end technologies. Imo, such a scope is too limited.

WPF for example is very powerful indeed. You can use it in a very simple way almost similar to Winforms or follow another path. The latter requires extensive studies - you can learn a lot from - does make sense in general.

Imo the articles on MSDN leave the reader behind with a false impression of reusability and increase in maintainability. The purpose of these articles is to make Microsoft look very smart. MSDN articles are a class of their own.

In reality, dependent on what you want to achieve, you combine different patterns and combine those into a consistent fashion. In the process of design and also during development requirements evolve and break the design and a different combination of interacting patterns is required. What you cannot do so simple is enabling them in order to be supported by the tool in a consistent fashion. Friends of mine had to redesign every control from ground up, starting with a rectangle that accepted text, simply displayed it and as long as the mouse did not hover over the control it is displayed as label, when the mouse focused the control it was drawn editable control (whatever the customization required). This you cannot tool in VS even it’s based on WPF. Because it will fairly make sense to become a component vendor for those components that make your product a lot more usable than those of your competitors or better more evil resell the technology that allows you quick migration. The risk is a not a big one. Since most of the C# people are former C++ programmers so the Not Invented Here Anti Pattern is applied by default.

WPF is a good compromise but you can reach the point soon, when things become complicated because you must go deep into the details. It’s a great technology indeed.

3

You said: The design of an application should be independent from the implementation technology.

And I wholeheartily agree! Yet I’ve seen an undue amount of posts and articles on a variety of fancy design methodologies since I got back from my coding hiatus…all of them seeming to climb on the backs of an equal number of compilers, IDE’s, modeling constructs, etc. And as I said about MVVM, all overly complicated, cryptically described, and geared again to competeing systems by authors impressed by how superior they can make what they’re touting today sound! Tomorrow they’ll be promoting something else, which is of course a necessity at the rate technology changes these days. But they do so not to truly offer anything better or new, but as a means to keeping their income levels up by changing the same methods around so they look and sound different!

Programmers can be a lot like any tech whores…that is always looking for and seeming to find something new and different in the belief that it will help them do a better job with a lot less work. But if you really look at the history of general design methodologies it’s easy to see that they all, no matter for what purposes they’ve been refactored to handle, start with basic design premises that are as obvious to any creative person as a black sky on a moonless night! And as they go beyond the basic, conditional rules, all that is added for the most part is dependent on the particular means used to create in that particular media! And programming code, no matter the language or tools used, and no matter if passive or active in use is just another form of or different kind of media!

Maybe I see it a little differently because I learned design as an Architectural major, and had done a lot of visual design work in Photography before that. But as I see it, unless you are coding for the requirements of a highly systemized project to begin with, under the auspices of an equally sytematic entity, or within a large group of coders where each one must adhere to system integrity so their work all fits together perfectly, accredited design systems are more of a hassle then they’re worth! Because by the time an individual has learned the basics of programming, he or she has already set their own methods of design to task, and with just a little preconception geared toward the task at hand, they will restructure their design methods to their current need a lot easier than it can ever be to adapt a given systems approach. In fact, I’ve never yet met a programmer who actually does use an accredited system of design, modeling, seperation, and implementation, that doesn’t admit to they’re own constant customization and restructuring of their system’s metrics as they see fit for every program they write! So how wrong could I be? ( Note: I’m more than willing to find out! )

My reason for being so critical of systemized approaches to programming design is that I did a little teaching a while back, and I was really amazed by how hungup many beginning students became on all the ballyhoo being idolized by tech writers on such topics. For some reason they percieve these systems as a fast track and forget that what they really need is to learn how to use code to make things work first!

4

Indeed. These topics are not trivial. Patterns and GUI is heavy. In the Java world you don’t have to be scared, almost everything is designed for use in customs development. Microsoft is little different
a) They follow a special thinking. One man know all the APIs and the corresponding products (MAPI for example). Those people should know everything in every fashion. Their philosophy tied to what we call an application oriented thinking.
b) MS is sometimes undecided whether to be very straight or coltish at the same time.
c) Pushing of certain topics in order to gain at least a few people’s attention, who maybe start adopting what they invented.

I can tell you the scenario for the example mentioned above. Planning combined with real time interaction with a (L2)/L3 (somewhere in-between) level system. Central element is a gantt and the whole application is data driven. The development started at the time of Winforms so a unique was of binding data was required and the controls had to be built from scratch. After WPF was a announced at the ‘future’ the whole framework was redesigned. They could have reused the WPF databinding but redesigning and improving the controls was easy. Since there is a very special cache (multidimensional ORM) that holds the objects and allows saving the caches stat at any time in order to be in the position to continue debugging when the application ‘crashed’ or the result of the optimization did not work as expected, they kept their own bindings. The advantage was simply replacing the original application (which is was implemented by someone else) was few days task.

Another advantage is, fully functional forms from scratch (complex) takes a few lines of code (assuming the code generated from the domain information) is available. The disadvantage is, 10 developers failed to learn what these 3 people engineered and improved over 7 years and use on a daily basis (rewritten 3 times). The next thing is - you need lot of similar projects to pay off the investment. In practice a friend of mine who had been partner in this company too, earns almost the same with writing bash scripts in the general hospital in our town as systems administrator and Oracle DBA.

The real power of .net with little manged C involved.

I agree. In order to make use of WPF you need to know a lot before. Without having experienced the drawback of the alternatives and getting to know the problems it’s hard to understand why such things do make sense. You understand such an article immediately if you see a way to solve a well known issue you have been seeking a solution for. Another side of the problem with hammer and the nail.

5

(Big Grin!) Me too! I Can tell from your writing style and vocabulary that you’ve been working around, or at least exposed to, much bigger and higher level application design and writing jobs…most likely under corporate conditions…than I’ve ever been lucky enough to experience myself. The obvious result of which is that you’ve also been made to use a much more system-ized approach to coding, design methods, and the stricter tools this kind of programming requires, like ModelMaker, Agile, and a lot more I can’t remember at the moment. Add good secure source control, collaboration tools, and possibly a wide variety of client conditional rules, and I can only imagine how complicated and structured you work might be!

I may never have used many of these systems or tools in my own efforts, but I am aware of them, and have spent a lot of time trying to grok what they’re all about. As I mentioned last night, too many of the novice Delphinians I worked with got their heads screwed up trying to assimilate all of this kind of stuff in the belief it was all very necessary…and long before they had even reached the point of basic adequacy with the language! And though I tried my best to make them understand how unimportant these tools, systems, and topics would remain…at least till they could claim a better proficiency as general application programmers…and pretend none of them even exist for a couple of years, I couldn’t pretend that I hadn’t gone through the same exact situation and worry myself! It’s quite normal to think that way!

So what finally worked for me…that is, what I did to keep them away from these specialized issues without ignoring their need for simple, yet somewhat systemized ways of design that require little more than individual appreciation for the validity of discovering and inventing on their own how to work consistently but open to change as well. And once they understood how and why the need for adaptability made all the pre-structured systems wrong for them at this early stage of their programming lives, they were once again on track and ready to learn!

So I backed off from exploring additional language use as I had planned for the week, and instead showed them how I had gradually developed my own system…one that still serves me as well today as it did twenty years ago! I can’t explain it further here as it would take too much space and time, but I am working on a new Oxygene NET project…my first since getting back to this kind of coding…and have decided to make a case study of it for novices. I’m definitely going to take it all the way from first project considerations, through design basics, mapping and analysis, coding, and right on into installation and documentation. Doing so as I now start learning NET myself certainly won’t hurt me at all, and perhaps posting it around here in the future as well would be a good idea.