Should I postpone MVVM for now?

Should I postpone MVVM for now?

Old forum URL: forums.lhotka.net/forums/t/9692.aspx


Dedrik posted on Sunday, October 31, 2010

Some facts first, I am somewhat familiar with the CSLA, somewhat familiar with WPF and not familiar at all with the MVVM pattern, but nevertheless, I am starting a new WPF project that uses the CSLA framework.

In order to try to do the best job I can and not bite more than I can chew, I am thinking of bypassing implementing the MVVM pattern for now and just code the application  the old fashion way.

I expect the project to take me about 6 months to complete and during those 6 months I expect to spend considerable amount of time digging dipper into the CSLA/WPF. My hope is that by the end of the 6 months I would have gained enough understanding of the CSLA/WPF technologies that retrofitting the MVVM into the project would be easier for me then.

So I am looking for some advice:


*) Is it stupid for me not to start using the MVVM pattern right from the beginning?
*) Is it a good idea to delay implementing the MVVM patter for now?

Any advice is greatly appreciated.

Thanks.

RockfordLhotka replied on Sunday, October 31, 2010

Personally I find that the primary benefit of at least basic use of MVVM is that it simplifies my coding effort. Less code, less effort, more productivity. The other benefits like testability are nice as a bonus.

I think the trick to making it reasonably approachable is to avoid being dogmatic. I've been quite dogmatic - zero code-behind is my continual goal. But I'm very experienced with CSLA (I hope :) ) and pretty darn good with XAML. So I feel comfortable pursuing this relatively high goal.

But you don't need to. You can pursue a goal of minimizing code-behind, and follow the mantra that any code-behind is nothing more than glue between the view and viewmodel. That avoids a whole host of advanced XAML concepts you otherwise need to know how to implement (custom controls, attached properties, etc) - without radically compromising the MVVM benefits or overall architecture.

The risk, of course, is that you'll allow non-glue code to sneak into your code-behind - but as long as your goal is always there, that shouldn't get too bad.

In short - there are a number of issues you have to solve to really use WPF - including navigation, hookup of the view to the model (or viewmodel), etc. The best solution I've seen to these problems is my approach to MVVM - with or without a little code-behind here or there.

Copyright (c) Marimer LLC