Model-View-Presenter

WPF Composites likely lends itself to a return to plain old Model-View-Presenter (MVP) instead of Model-View-ViewModel (MVVM) due to its code-behind nature. MVP, in turn, is typically effective in supporting Test-Driven-Development (TDD) which may be relatively popular these days. See a basic example of using MVP with WPF-CPS in the separate Codeplex project WPF Composites Contrib.

This may invite many architectural questions. Where does Prism fit in? Or Caliburn Micro? Or MVVM Light? Or perhaps, we should ask if we should return to the Composite UI Application Block (CAB) that we may have used for WinForms? Also, how and where do Commands, RelayCommands, or DelegateCommands come into play?

No Best Practice Yet?

Personally, I think the requirements, context, and timeline of an individual project will determine the answers to the above. WPF Composites is an alternative approach (not a replacement to XAML) so it won't work for all cases but may turn out perfect for a quick, small kiosk implementation? Or maybe it will be perfect for building a small tool quickly with only a handful of screens where dependency injection, IoC containers, and weak references may be unnecessary? Where managing hundreds of user controls won't be a concern? Or, maybe it could prove useful merely as an add-on to an existing XAML-based project?

In the short term, for very tiny apps, tools, or prototypes, there may be nothing wrong with the limited approach that I show in my Demo App? There, in lieu of Commands, I store Actions in the global properties dictionary of Application.Current like so:

Application.Current.Properties["RegionOneAction1"] = new Action<object, RoutedEventArgs>( (o, ev) =>
{
      MessageBox.Show("I can be called from anywhere.");
});   
I know: just wrong! But I don't have a best practice yet. See the separate Codeplex project WPF Composites Contrib for a basic example of an ActionAggregator that may be useful? Yet, perhaps, static methods might be another, better approach? Or, you could likely still use regular WPF Commands, etc. in some way, shape, or form? Or your own homegrown delegates/events/weak references solution? Or Unity? Or . . . The C# community at-large may be able to help me with this one?

UserControls and Prism Regions

The addition of UserControl as an IParent did make me immediately think of Prism regions as well. In the Demo App, I create a UserControlRegion (via a Border) to swap UserControls in and out of similar to a Prism region? Another similar, simple example exists in the separate Codeplex project WPF Composites Contrib.

In the Demo App, I performed initial testing with the RedGate ANTS Memory Profiler to check for memory leaks in opening/closing top-level Tabs and in opening/closing UserControls within a Tab. Memory leaks were fixed except for TabItem 5 with the WindowsFormHost/Chart. Consequently, despite the limitations of my approach (for example, careful monitoring and cleanup of global Action handles is required), it does appear viable for small apps that don't have major scalability concerns?

I invite discussion on what architectures might suit WPF Composites well, but I ask that trolls refrain from "drive-by criticism" of the obvious flaws in my scratch Demo App code. It is not meant to show any best practice but merely to demonstrate the WPF Composites in action in a limited use case which it does.

My thought is that my main focus is to build this WPF code-behind library, not to build a dependency-injection-based framework to compete with Prism, etc. Perhaps, another developer may spearhead this open-source effort, building a robust framework founded on WPF Composites in the future?

Last edited Mar 24, 2014 at 6:07 AM by stagathome0069, version 32

Comments

No comments yet.