I saw an excellent MVVM presentation in Milwaukee last month. Certainly not claiming to have grokked it all but one of the core points seemed to be that the less code there is in the code-behind, the better.



>I just can't wrap my head around why one would even want to try MVVM in a Winforms environment. The way the binding works, the generated winforms code ... I just don't see how you can decouple in a meaningful way. My winforms apps - based on Strataframe BOs - work nicely but they are what they are. I would not use them as a design model for a WPF-MVVM-EF that set out to accomplish the same thing.
>
>To me, the whole WPF - MVVM - EF paradigm is its own animal. I just went into it with my brain as checked out of the winforms way of thinking as I turned off the VFP switch when I looked at .NET.
>
>As to WPF code-behind, I'm still wondering if there isn't some place for code strictly related to UI issues ( though I haven't found a need for it ). I don't work with others doing design and I'm not deeply enough into Blend to figure out if this is ever necessary or appropriate, but I definitely get the command model and a completely UI ignorant View Model.
>
>But there is still a loooong road to travel. <g>
>
>
>>>I have mixed emotions about Prism. It is certainly hellaciously complicated, but I'm hoping once I've been through all the steps once I will have "framework" I can start with that I am comfortable using in the future. The module and region stuff is pretty cool. Karl Schifflett says he has a Feature Builder presentation like In-the-box coming for Prism so prehaps that will help. There are some pretty good examples. I like Veeneman's stuff on codeplex : ( for lurkers )
>>>
>>>http://www.codeproject.com/KB/WPF/ViewSwitchingAppsPrism4.aspx
>>>
>>>but I am somewhat frustrated nobody has really demonstrated it all the way to the backend with EF ( especially in how the repository thing works in creating test data vs run time )
>>>
>>>I get the MVVM stuff and see the value of it - especially for unit testing. I'm still messing with what goes in the model and what goes in the view model but I am pretty clear on what doesn't go in the view and that makes a lot of sense to me.
>>
>>I've been pondering this. It seems to me that, from a purist POV, for WPF it implies that there should be *absolutely NO* code behind associated with the View. Everything in XAML. Period. I'm trying to work that way so the guys doing the UI in XAML don't even need to know that C# exists. But then I wonder about the suitability of MVVM as a general pattern for other UIs. If you want to use a ViewModel that is optimised for WPF in, say, a WinForms environment then you would still need to have a fair amount of C# code in the View and things get unavoidably messy. Even using MVVM with Silverlight seems to get blurry because I always end up splitting what should be the VM between server and client side code.
>>
>>Prism? There are times when it is a useful approach. Many, many other times when it is certainly over-kill.
>>
>>Nice the see that Rick is coming around to WPF though (g,d&r from Rick)
>>
>>>I love WPF but I have a feeling I am going to have to really up my game with Blend before I'm going to be as productive with it as I'd like to be.
>>>
>>>It really is like completely starting over again but hey, I'm young ...
>>>
>>>
>>>>No not using Prism, although I'm getting ready to start work on a WPF app and I might check it out. I think most of the MVVM schemes are way too complex and they don't really make things easier...
>>>>
>>>>NuGet - yup just published a bunch of stuff on NuGet (West Wind Web Toolkit stuff which includes all the general purpose utility tools too as a separate NuGet package).
>>>>
>>>>NuGet is one of the nicer things Microsoft has done in a while... Really sweet to be able to just dump components into a project off the Web...
>>>>
>>>>+++ Rick ---
>>>>
>>>>>Thanks, Rick. Can't find a way to do it with CodeRush either.
>>>>>
>>>>>I got search and replace to work pretty well in cloning a project ( Prism module ) once I remembered to do case sensitive searches (c#) for names and realized it wasn't going to actually rename the files.
>>>>>
>>>>>Once I get this prism module stuff working the way I want it i'm going to give some serious thought to templating it.
>>>>>
>>>>>I'm also trying to figure out some good ways to use Feature Extension and Instant Feature Builder as Karl Shifflett does in In the Box.
>>>>>
>>>>>Have you used that or NuGet? ( The more I do the Prism stuff the more I am looking for some RAD shortcuts.)
>>>>>
>>>>>
>>>>>
>>>>>>Oh how I wish. Neither Visual Studio nor Refactor! refactorings support renaming namespaces.
>>>>>>
>>>>>>I think there are issues on how these tools can track changes once the namespace actually changes. Making replacements afterwards breaks the Code model in memory. Just a guess, but I'm sure it's occurred to the Refactor! folks before - it if it was more easily doable it could be done.
>>>>>>
>>>>>>However, I typically use a search and replace in files and that works fairly well and is quick..
>>>>>>
>>>>>>+++ Rick ---
>>>>>>
>>>>>>>Bringing in stuff from other people's Prism samples, for example and need to reset namespaces.
>>>>>>>
>>>>>>>VS 2010 - seem to remember there is a clever way to change the namespace on a lot of files at once ( yeah, I know I can do a global search and replace but I thought there might be one place I can sync namespaces - or a 3rd party goody that does it )