MVVM in Practice

[DoJa]

So i've been reading/watching lots about MVVM and pretty much got my head around the concept but still struggling a little with the practical implementation side of it.

I have read that a benefit of MVVM is that it makes testing easier: You can have two views (an presumably two view-models) for one Model. So perhaps a POS/Till system with a view where you can add products to an invoice and then another view to test the functionality which shows the contents of various datatables in a datagrid.

Is this a reasonable use case and scenario?

If the above is correct, the next question is with respect to how this all works in visual studio.

Again please correct me if I am wrong, but as I understand it the MainWindow.xaml is your default view, the MainWindow.xaml.cs is your Model and then you create a new class MainWindowViewModel.cs for the view model. All good so far, aside from the fact that VS likes to link the view and the model together. - You cannot create a new page or window without VS creating a .xaml.cs 'model' file to go with it. So what should I do in the above example where I would like to have multiple views to a model for testing purposes or whatever. Do I just leave the additional .xaml.cs files blank for each additional view for the same model? or can I safely delete them ? Or do I need them to some how link them to the 'base' model?

Lastly, Is MVVM a sensible approach for developing a largish WPF application? As an individual programmer who will be working on all aspects of the program (view, model and view model) is there enough benefits of MVVM to make it worth applying at all or am I wasting my time writing a load of extra code which wont really be useful unless used in a large team/corporate environment where different people or teams would be collaborating on different elements of the program?

 

[Herman]

I will skip the first part of the question, as I have no former experience with WPF and MVVM testing (although I have developped medium-sized applications to some success with both), if not to say that there are many types of testing. Unit tests are UI-agnostic, and are perfectly integrated into visual studio (add a project to your solution using the tests application template and read the docs). If you do UI testing or live data-driven testing, usually you will want a third party product to help you design and manage your tests in a project file with the tools you will need. I have managed a project of around 450 UI tests on an older VB6 application using a testing solution called TestComplete, from SmartBear.

Lastly, Is MVVM a sensible approach for developing a largish WPF application? As an individual programmer who will be working on all aspects of the program (view, model and view model) is there enough benefits of MVVM to make it worth applying at all or am I wasting my time writing a load of extra code which wont really be useful unless used in a large team/corporate environment where different people or teams would be collaborating on different elements of the program?

MVVM shows the most benefits in particular in big, data-intensive applications by drastically reducing the amount of boiler-plate code, and virtually eliminate classic UI glue code, but the flipside is that you need to implement MVVM correctly from the start and have a good long look at your UML before you start putting it all together. From your uncertainty, you probably have not used WPF or MVVM all that much yet, otherwise you would immediately see how it could benefit you or not. Really wrapping your head around it at first is a minor paradigm shift in how you think of designing your architecture, so if you are still just a beginner, you might be better served doing your largeish project in a language and platform you are more familiar with. If the goal is one of learning along the way, then yes, I would absolutely recommend you at least try it and figure it out. The WPF and MVVM approach embodies everything good about object-oriented programming in regards with separation of concerns and minimizing code maintenance costs. How effective you are at wielding the tools will determine how successful you are with it.

 

[DoJa]

Hi Herman,

Thanks for your reply. You are correct, I am new to WPF. My experience is with winforms but it has a number of limitations which are solved with WPF.

Basically I'm trying to write Version 4 of an application which is currently a winforms app but in WPF. I want to take advantage of as many best practice techniques and architecture paradigms as possible (where it will be beneficial) but I am also in a situation where I need a working version of v4.0 as soon as possible because V.30 is lacking a lot of new functionality which the business now requires.

So there needs to be a compromise between getting things done now and doing things right for the future.

Perhaps I should write v4 using WPF but without concerning myself with MVVM and save that for v5 which would make for an easier transition.

What do you think?

 

[Herman]

You don't really have a big choice between WPF and MVVM, they are made to go together. WPF without MVVM is just meh. If you need to deliver this application, then do it with whatever requires the least work (stay in WinForms), and use the next project's V1 to start figuring it out, when you have a whole dev cycle in front of you to make adjustments.