Advance Your Composite Application MVVM to the Next Level – Use Attributes to Automatically Populate Your View Model with Service Calls

Abstract

MVVM is a proven design pattern in WFP/Silverlight world. Its use helps achieve separation of concerns, frees UI from any logic to enhance testing, and generally makes the code easier to understand and maintain. In many LOB multi-tier applications MVVM is extended to include a presenter class. Presenter usually controls the view model, receives necessary services from dependency injection container and has some logic to populate the view model with business entities and/or reference data and send any changes back. The resulting code is usually pretty clean, easy to maintain and test. This article argues though that most of the code in such presenters to populate the view models is also very mechanical, routine, boring and can be avoided all together by introducing small attribute-based view model framework to declaratively populate view models from service calls and avoid extra coding, and, thus, avoid writing extra mechanical, routine, and boring tests.

If you prefer the “code first” approach VS 2008 solution can be downloaded here: MVVMAttributes.zip

Running multiple WPF applications in the same process using AppDomains

Why?

There are various reasons you may want to run several full-blown independent WPF applications side-by-side in the same process. In my particular case this was a client project where we were building a composite WPF trading desk. One of the requirements was to be able to run different versions of the same component (montage, P&L, blotter, etc.) side-by-side but within seemingly integrated environment. The best solution turned out to be running different versions in completely independent environment (application) and only communicate across domains using a thin protocol to provide “integrated” look and feel. Running components in separate domains let us avoid all the problems that come with signing, versioning, evolving dependencies, and many more.

This post is a step by step guide to demonstrate the techniques involved.

Running WPF Application with Multiple UI Threads

Introduction

It’s a good, time-proven practice to perform long, CPU intensive tasks on some sort of a background thread to improve your UI thread responsiveness. Sometimes though UI-related tasks themselves can be quite expensive. WPF, for examples, forces you to do all UI work on the thread that created the UI. A very flexible WPF measure/layout paradigm for UI rendering also comes with high CPU usage cost. In a very UI intensive application (for example, trading app with about ten windows showing real-time montage and blotter data) simply the cost of generating and laying out visuals can become too high for a single thread to keep up. When your UI thread saturates individual windows may start skip rendering cycles, become slow to response to user input, or even freeze. If your UI thread approaches this kind of saturation you should consider creating dedicated UI threads for some (or all) of your UI-intensive windows. This post is a step by step walk-through of doing just that.

Composite WPF: Improving Out-of-the-Box Module Dependency Resolution

Introduction

Microsoft has recently released its long awaited composite application framework for WPF (http://www.codeplex.com/CompositeWPF). As a heavy user and a big fan of the original CAB/Smart Client framework I rushed to explore it. To say that I was impressed is to say nothing. The [patterns & practices] team has done a tremendous job. The first thing that amazed me is the quality of the supporting documentation: direct mentioning and in-depth discussion of patterns used and architectural  decisions made, extensive tutorials and walk-throughs on all major concepts, and very cool reference implementation. So I immersed myself in CompositeWPF implementation to figure out how it stands against its CAB predecessor. I was specifically interested to see what CAB’s deficiencies were addressed and what are the areas improved and polished. So I started from the very beginning…

At the core of the composite application framework lies dynamic discovery and dependency resolution of its modules. This article discusses dependency resolution implementation in the new framework, its limitations (in both new and original frameworks), and suggests the ways to overcome those limitations.