Question

We were building out the next version of an in-house thick-client application using WPF/Prism (Composite Application Library). As we were nearly done with the client our team was put under new management and shortly thereafter:

1. We were then directed to drop the Prism framework to keep things simple. This includes not using any type of Inversion of Control.

2. We were directed to build out the WPF application without using MVVM or similar; and more along the lines of a traditional WinForm application. The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it’s doing without having to traverse through a view-model (or similar).

3. We have now been tasked with building out the WPF application using one primary Window, use a Frame Control to contain the content, and use a Ribbon outside of the frame for the menu items. Reason we were provided to use Frame Control:

   a. We will show a view in the Frame with a Page (not a user control) and then load the page in the Frame.

   b. When a new view is to be shown in the Frame, the current view (Page) will be closed/disposed and the new view (Page) will take its place in the Frame.

   c. When a developer looks at the Page in design view, (s)he will be able to click on any control and see exactly what is being done.

Given the restrictions of 1 and 2 above, we’d like to present another method of building out the application that:

1. Can be presented as an alternative to using the “Frame Methodology” (item 3 above) but still provides the same type of functionality.

2. Does not use MVVM (see #1 and #2 above).

Provided the direction we’ve been given, any suggestions as to an alternative we can present? I’d request that the responses be kept on the professional level and thank you in advance.

Answer 1

I’d personally try to argue to use Martin Fowler’s Presentation Model. (That’s a joke, btw…)

Basically, you’re being given a restriction that says “Use WPF, but don’t use any of the features that make WPF usable.” It really sounds like your requirements are such that you would be much better off explaining, reasonably, the advantages of patterns like MVVM.

It sounds like the weird requirements are really boiling down to this:

The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it’s doing

If that’s the main issue, and the reason you’re avoiding MVVM and other similar patterns, I would seriously take the time to educate the management. Looking at a Command, by name, instead of an event, by name (which is what you see in the designer) is really no more difficult.

However, in a large scale application, the separation of concerns is key. Even a properly designed Windows Forms application requires a clean separation of concerns – but with event based programming, this becomes much more difficult, especially from the designer. If you try to develop a large scale, clean, application using an event approach, you’ll have event handlers, but those event handlers will all eventually need to delegate their work to a separate component.

This is actually adding an extra level of effort, from an understandability and maintenance point of view, on top of what you get with MVVM. With MVVM, you only look to the ViewModel, which is very discoverable.

---

BTW – The “rationale” for using a Page instead of a UserControl doesn’t make any sense. You can do exactly the same thing you’re describing with UserControls… The only reason to use a Frame and Page is if you want to take advantage of navigation, in which case, you can’t dispose the old pages directly (or they get regenerated constantly). Also, the navigation tools probably wouldn’t be used with a ribbon – the two conceptual models are quite different.