What is your experience with abandoning MVVM for UserControl-based WPF architecture?

we can inherit our non-XAML UserControls from each other

I don't understand. What about MVVM precludes inheritance?

we use as much code-behind as we want which expedites development

Code-behind is fine as long as it's code that is concerned with the view. ie. not business logic that you want to test. Separation of concerns and all.

You can still do MVVM whilst doing everything in code - even your view. MVVM is not about zero code behind. It's about separating concerns and the benefits you derive from that. If you have no need to design your views in Blend, then by all means you can manifest much or all of the view as code. Heck, even if you do need to do work in Blend, there's a certain amount of your view that could still be manifested as code. You just need to evaluate the trade-offs and make conscious and informed decisions.

attaching the infragistic controls directly to our model class coming from the web service cleared up dozens of little binding problems we were having with binding Infragistics to ObservableCollections

The Infragistics controls are extremely poor. There, I said it. If it's an option, don't use them. If it is not an option (and I've been in this position too), you can normally work around many issues with attached behaviors and other techniques. It's a hassle, yes, but don't blame MVVM - blame Infragistics for producing a control set that is so at odds with the WPF platform.

even in straight WPF, the lack of ObservableCollections make problems like not being able to create a simple Menu go away

I don't understand this point at all. ObservableCollections are part of WPF, not MVVM. And having read your question (again - I replied to it not long after you submitted it) I'd say this is just your misunderstanding of how WPF works - nothing to do with MVVM at all.

we are replacing the EventAggregator one-by-one with direct events using UserControls and code behind, which cleared up all kinds of problems with events

Right tool for the right job. If you're able to use direct events, then you can do so whether you're using MVVM or not. MVVM does not in any way require the use of the event aggregator pattern, so again your point is unclear. The event aggregator pattern can be used to ensure that different components can collaborate at runtime without having any compile-time dependencies. By using standard CLR events, you're creating strong dependencies between your components. Should you ever want to use them in isolation, you're gonna have one heck of a time.

In summary, this doesn't much of a case against MVVM, but more a lack of understanding. I think you're swimming upstream and I'd advise you to take a closer look at MVVM. It's not a silver bullet or one-size-fits-all pattern, but it can sure help create a fantastic basis for your WPF/SL applications when used correctly.

I started doing WPF applications in a FFA (free-for-all) design pattern like this and I won't go back it, even for a small projects. Though it feels like you are more productive going right to the source, bare-metal UI, I came to the conclusion it's more a perception of productivity because you get instant gratification.

Consider: TextBlock.Text = "HelloWorld". No ViewModel to construct, no gluing the V and VM or binding setups. Hit F5 and we see "HelloWorld" in all it's glory. My problem with this is multifaceted. Here is a couple of my biggest issues:

• Separation of concerns. Without it, code navigation, bug fixing,extensibility and general maintenanceis severely hindered. Adding afeature to an application would bemore liken to achoose-your-own-adventure book or anexercise in quantum physics than itis actually getting something done. If you have a predictable way tobuild your app, you have apredictable way to work on it.

  Flexibility of the UI. When using the FFA pattern, I found myability to design UI in myapplications was near impossible. Too many times did I have a control Icouldn't design in Blend. It wouldjust give a red border with anexception. Some code-behind I hadused something else that wasn'tusable in design mode causing anissue. Moving to MVVM magicallyfixed all my Blend issues. If I geta red border in Blend now, I KNOWit's a problem with my presentationcode. Not anything else.

So using FFA may get your V1 out the door quick, but the PHBs will be wondering why v1.5 is going to take four times longer than v1. We've all been there :)

I think if you want to do something like this, I would work with lookless controls, where you define UI "PARTS", making it very Blendable. You get reference to the UI controls via the OnApplyTemplate. These controls are totally stylable and inheritable. It is your View where you would use these controls and pull data from binding, passing it to your lookless controls. The View, IMO, should always be glue for the VM to bind to these kinds of controls.

For the Infragistics controls you are having problems with, assuming you are using Prism, you should make a custom region adaptor for it. This lets you code EXACTLY how controls will be added to the Infragistics. No binding involved. View injection will just work like you are used to once you get that built in.

I've seen some people have problems like these in MVVM, but I believe it's just taking MVVM too literally. Not everything gets evented by a messenger. My ~40 view (and growing) application has around 5 composite events. I inherit controls, I use view injection on things that aren't even panels or content controls. Sometimes I have codebehind handle presentation related code/events...And...really, I advocate MVVM and I don't give a @$&% about testing :)

I tried this and ended up going back to MVVM. You end up with the same event-driven spagetti-coded mess you always ended up with in Windows Forms. If I never have to do another myLabel.Text = this.MyLabelText I will be happy.

Don't get me wrong - MVVM is harder to stick with and you really have to know WPF to pull it off.

You lose a lot by not using it, though, including a lot of the ability to use Expression Blend to style your controls and DataTemplates.