Dependency injection

Below is a presentation I've recently made for my colleagues.

My fellow java developer exclaimed: "But this is ridiculous to make presentations about DI! Everybody supposed to know it!" And this is a big difference between two worlds .Net & Java. In java even junior developers know benefits of DI, whereas you can find a senior developer having no knowledge of DI in .Net realm. I consider it to be a consequence of paying way to much attention to developers' tools by Microsoft. LightSwitch and WebMatrix are a justification to my words. Hey guys, do you really think we are that stupid? Why constantly lower the bar?

Nevertheles, if you are interested, check it out and browse for code examples that come with my presentation.

Dependency injection

Code as I promised.

Good luck!

Business Objects validation in WPF wizard

Oh dear! Is it really me writing? Well, yeah, it is me!

I had a lot of fun in Mediterranean yachting and now I am full of strength to manage with my thoughts' flow. =)

While writing this post I understood that I chose the very interesting theme to my mind - WPF wizard component development that I've done for my projects. But then I realized that it would take a year to highlight all the process with my speed of posting, so I came back to the original title and focused on the particular theme. I'll try to write on WPF wizard later on, but to keep your interested I'm going to include wizard's sources.

As I've mentioned in my previuos posts on DM-V-VM pattern I don't edit objects in most of UIs. The reason is simple - ViewModel doesn't track edited object state. I do it in wizards. WPF doesn't contain such a useful component as a wizard by default so you have 2 ways out: 1st - pay someone for ready custom component and the 2nd one - write your own. I chose 2nd one =) as I often did. It was a very big work that brought tons of difficulties and challenges but was a lot of fun to solve. Propably the biggest challenge was UI integration in validation process where UI could track underlying objects' state and react respectively avoiding user from saving objects in an inconsistent state. I knew about validation in WPF binding, but it was not quite the thing I needed. (In WPF that goes with .Net 3.5 business objects validation can be plugged in validation process easily by using ValidatesOnError binding property and IDataErrorInfo interface in object, but still it is not quite one I needed). Karl Shifflet wrote a wonderful article on validation and WPF business applications developement generally, here it is: http://www.codeproject.com/KB/WPF/WPFBusinessAppsPartThree.aspx .

As an alternative to editing objects in wizard you can use this approach, which I've mentioned earlier.

So what do I need and what do I want?

I want:

• UI to track underlying objects' state automatically and react respectively - buttons Next, Save should be disabled in case an underlying object is in invalid state; in other words wizard should not let you make a mistake;
• developer writing wizard code to avoid taking part in validation process, in other words validation must start automatically in a transparent way, no code-behind with validation code;

I have:

• Validation in WPF binding engine already exists. One can plug in by writing his own ValidationRule descendant. There also is a static class Validation that provide means to set ErrorTemplate for UI control and get errors collection. So why doesn't it fit our needs? The reason is simple - it validates the UI data - not underlying objects, but we need a unified process that will validate business objects decoupled from UI technology. Therefore we won't use WPF validation as a main engine, but only as an extensibility point;
• Validation Application Block (VAB), that was developed to validate objects, can be found in Enterprise library (EL);
• There is command notion in WPF that can control UI state. I wrote about'em in previous posts.

Well, it seems that we have all we need! So let's go on.

First of all let's check out this scenario: we've got a wizard that edits a human/visitor (whatever) entity.

1. you fill in first name, last name and other fields at wizard's first page, and the first name field is mandatory.
2. you provide an entity with the access data such as login, password and password confirmation in the second page;
3. you fill all the blahblahblah fields in the rest of a wizard's pages... =)

Entity you edit in my wizard is applied to DataContext property, thus enabling all the visual tree (pages with controls in it) to inherit the last one.

Every UI control, which triggers some action, is bounded with a command. Every command is wrapped in alreasy familiar CommandModel class. Said models are holding command's state and execution logic. And what I intend to do is to delegate them validation.

First I used to delegate validation logic to my domain objects (you can read about this approach here) but it made my wizard control tightly coupled with my domain model, which is ugly! So I've changed a direction and made my commands validating edited entities. I use Validation Application Block from Enterprise Library. David Hayden has a tons of tutorials on p'n'p's products, including this set of articles on VAB, so I won't write on how VAB is working because you can read everything there.

Wizard edit process is divided into pages that holds some logical associated data, and this logical association correlates with ValidationRuleSet notion, so every WizardPage carries a RuleSet property, that must be set on developement stage.

When it comes to validation I simply call VAB's facade to do the work.

Here is what our visitor class might look like:

You see it has a property Name that is marked with StringLengthValidator attribute [1;200) with the CommanRuleSet ruleset name, and wizard page that edit this property must have the same ruleset name.

Now, when we finished with validation we can start writing our commands logic.

I have the following commands in wizard:

• NextPage - a command that transfers you to the next page;
• PrevPage - a command that transfers you to the previous page;
• GoToPage - a command that performs a gap to the specified number of pages;
• Save - a command that triggers Finish event;
• Cancel - a command that triggers Cancel event;
• Help - a command that shows a user manual;

I'll make an example with the NextPage Command. Command checks whether an entity is valid with corresponding ruleSet, and whether the current page is not last and whether this page is not marked as invalid by WPF Validation manager (it is the extensibility point):

This logic will be called automatically by WPF CommandManager and will reflect state of edited object on NextButton button.

Extensibility point.

Imagine a following scenario:

you edit a credential object that is formed by a Login and Password properties. You have 1 TextBox - Login, and 2 PasswordBoxes - for Password and PasswordConfirmation. This credential object (lets call it LoginCredential) is in DataContext property of wizardpage. You have binded TextBox's Text property to a Login property of credential, text from first PasswordBox use assing to Password property of credential in code-behind. However, in order to validate a password you need user to confirm it and a LoginCrredential class doesn't have such a property (PasswordConfirmation) and never have to! How we will keep our Buttons' state syncronized wth data, when they should be inactive unless user has confirmed his password?

Well, here is the place where I plug in a WPF validation process. In this case I don't need to validate business object's data and should validate only that part of data, which is located in UI.

I've written a ValidationHelper class to streamline my validation code.

There is an attachable property Bag, which can be attached to any DependencyObject and bound with some data (it is useful when you have no properties to bind).

Back to our scenario you'll have to bind ValidationHelper.Bag on first PasswordBox to Password property of underlying credential. You have to do this because in PasswordBox a Password property is not a dependency property (I know that there is a security issue with my attached property take it as an example).

The key element in integration is the PasswordValidationRule that can be seen in the picture above. It is a custom descendant of WPF ValidationRule class. I had to do some code-behind here because, as I've mentioned earlier, Password is not a dependecy property. In this code-behind I obtain binding expression for ValidationHelper.Bag property and force it to update source, thus forcing validation.

I need to send PasswordCopy and WizardPage objects from UI into my ValidationRule object that is not a DependencyObject and even isn't in Logical or VisualTree. What we need to do is to attach virtual branch to the LogicalTree and this problem was perfectly solved by Josh Smith. You can read about this approach in his article. Here’s a brief description. ValidationRule is not a descendant of DependencyObject class so you can't bind its properties, but you can write a surrogate DependencyObject descendant class that will keep one dependency property that can be bound with data. This data is being sent into the dummy holder in resources (DataContextBridge) by means of OneWayToSource binding. After that you can bind a surrogate object Value property to DataContextBridge.

The only thing that left is to write code for ValidationRule. It compares original password string with its copy and mark a wizard page as invalid in case passwords are not identical:

There are two methods in ValidationHelper - MarkInvalid and ClearInvalid that are simply wrappers around WPF Validation class. All that is required to make UI element compatible with ValidationHelper is to attach ValidationHelper.Bag property and bind it with itself (as it is done in WizardPage's default style).

Well, here we are - our validation process in wizard is ready.

In a simple scenario all that developer will have to do is to mark entities with validation attributes, or even configure 'em in enterprise library configuration tool and nothing else. All the rest work will be done by wizard automatically absolutly in an absolutely transparent manner.

Good luck!

P.S. sources are coming on a little bit later.

WPF command & CAB command - run into one another

My previous post was dedicated to the set of classes that constitutes my DM-V-VM pattern implementation being an extension to the smart client software factory (SCSF - CAB based factory) & Kent Boogaart's SCSFContrib (WPF CAB extensions project).

An interesting point was ActionViewModel class that contains and binds all view's commands. But there is another implementation of command pattern in CAB. Which of them a smart programmer should use? What are the pros and cons of each variant?

In CAB's command implementation you have access to an IoС-container and a whole lot of CAB's infrastructure (local services, resources, views). At the same time WPF command is tightly integrated in UI engine, and UI control is the WPF engine's problem. Is there a way to gain united advantages?

The answer is yes and it follows below.

Honestly speaking there is an implementation of merged CAB and WPF commands in Kent Boogaart's SCSFContrib project (WPF integration in CAB). It is a WrappedCabCommand, but I see a huge disadvantage in this implementation - it lacks ability to pass a parameter to a command. I solved this problem by extending Kent's approach.

IActionCatalogService

My main enhancement to WrappedCabCommand is the use of CAB's local service IActionCatalogService as main command executor and state controller. Here you can find a good description of this SCSF part. This service links named actions with methods, marked with [Action(ActionName)] attribute,

registrers conditions - a code that controls action state (whether it can be executed or not),

and allows executing named action (invokes a pipe of subscribed methods).

Method marked with [Action(ActionName)] attribute should be public and match an ActionDelegate delegate signature. Subscribing process is controlled by ActionStrategy from SCSF, that is plugged into the ObjectBuilder strategy chain.

Action conditions are classes that implement IActionCondition interface. Their respective method is automatically invoked by IActionCatalogService before executing, or it could be invoked externally by a client code through the same IActionCatalogService service. The service builds an action pipeline, and results an integral decision of all IActionCondition classes registered for concrete action.

СAB Command.

Commands in CAB are a collection of Command objects stored in WorkItem and indexed by unique string identifier. CAB itself works with commands by means of CommandAdapter class, controling subscribers, command invokers etc. Commands are created by a CommandStrategy that is plugged in the ObjectBuilder strategies chain. Command is created when the strategy meets in created object public methods marked with [CommandHandler(CommandName)] attribute and matching the EventHandler delegate signature. CommandAdapter keeps internal invokers and subscribers tables for the named commands. And when it catches the specified event in invoker, WorkItem invokes all methods subscribed by means of [CommandHandler(CommandName)] attribute.

Adding list view item as a ActivateOverview command invoker with Selected event

ActivateOverview command's subscriber method.

WPF Command.

In WPF commands are presented by classe implementing ICommand interface. There are 2 built-in command classes in WPF library - RoutedCommand and RoutedUICommand. They routes their CanExecute and Executed events in a visual-tree as it follows from their name. The built-in commands doesn't contains any predefined logic and simply allows to handle it by any object from VisualTree that is subbscribed to this command via CommandBinding. UI elements, that can be binded to a command, should implement ICommandSource interface. This interface contains the following properties: Command - the command itself (ICommand), CommandParameter - parameter being passed to the command handler (optional property) and CommandTarget - target - an object particular command will be executed on (optional property).

Come together!

I've chosen a CommandModel class invented by Dan Crevier as a foundation for merged CAB and WPF commands entity.

The ModuleCommand is the idea.

ModuleCommand class interface. IActionCatalogService is injected by CAB's IoC-container while created.

This class finds a CAB command object by name - CommandName.

I've made a convention in unique command naming, it is identifies by the following way - CommandName identifies Command and IActionCatalog Service action, CommandName with prefixes Before[CommandName] and After[CommandName] identifies command-triggers being executed before and after actual command execution respectively.

WPF invokes the ModuleCommand's object overrided OnQueryEnabled method automatically. It queries CAB command and ActionConditions if the command can be executed, promoting all the specific logic into the external infrastructure code (IActionCatalogService CanExecute call), and WPF reflects the command state in UI automatically - the UI element will be enabled or disabled.

There is an ActionTarget property in a class - it is an optional parameter, that the command will pass to the subscribed method automatically by means of IActionCatalogService.

WPF invokes the ModuleCommand's object overrided OnExecute method automatically when it catches event that triggers the command execution and delegates the execution to my ModuleCommand object that in turn delegates it to the Command and Action subscribers.

Thus the problem of merging WPF and CAB commands is being solved by means of IActionCatalogService. UI element is binded with ModuleCommand by CommandBinding in a visual tree, and IActionCatalogService links ModuleCommand with the CAB infrastructure and allows to pass a target and parameter objects to a command handler.

CAB command is still can be used when the logic is simple.

I said work!

Let's assemble an example now. We will modify the code from the previous post. Main changes will happen with FooViewModel class. There is only one type of command objects in it's collection now. There will be no more command classes with hardcoded logic.

but we'll need a command handler class and an action codition class. Here they are:


+ unique strings list.

Code for download: here.

Good luck!

PS: A very interseting approach was demonstrated by wpf-rockstar Josh Smith in this article. He suggests to make RoutedCommand "smarter", by adding it an ability to keep logic itself. Josh inherits his class from RoutedCommand and introduces an attachable-property, marking UI element as a command handler, and also he introduces 2 abstract methods OnCanExecuteCore and OnExecuteCore to be overriden in descendant classes. Other words we could replace our CommandModel class with SmartRoutedCommand, but it would involve xaml complexity.

PPS: remembered that I saw another approach that was built on CAB's EventBroker. But I don't like it though it is easier as it mixes the entities.

DataModel-View-ViewModel in WPF. Part 3 Example.

This is the last part on DM-V-VM pattern overview. In this part we'll write a simple WPF application built on this pattern.

DM-V-VM

Let's suppose that we have an object of class Foo that is provided by the SEModel class (parameterized with Foo and FooProvider types). It will be a demonstration of simplicity that SEModel gives - we don't have to write datamodel class, only provider class will be written.




All the logic is contained in a FooViewModel class. It is derived from ActionsViewModel as we'll have some actions triggers in UI (buttons). The actions are represented by two CommandModels - IncCommandModel and DecCommandModel. IncCommandModel increments Foo.Bar property when executed and DecCommandModel decrements it respectively. The DataModel is asked to refresh on View's Load event. DataModel will fetch data asyncronously and throw an event on UI thread as described in a first post.

CommandModel classes implements logic for editing underlying data (Foo object) that is referenced in CommandParameter property of UI command triggers (objects that implement ICommandSource interface - Buttons in our example).

Now it is a view's turn.

In this example we won't use an IoC-container and will hardcode all dependecies in our classes. View creates ViewModel on it's Initialized event.



And keeping in mind that ViewModel sets itself to the DataContext property of View (window in our case) we know that all visual tree of our view will inherit VM in DataContext property. So just put a ContentControl in a view, bind it's Content property to VM and write a template to render VM.



The only evil SEModel can bring - is lack of ability to bind to it's Entity property. DataBinding just can't fetch the object even if all paths are accurate in 2 or more level templates. But this issue can be avoided easily - just put your object in View's resources in DataModelLoaded event in ViewModel and reference it in Binding via Source property.



This is how our application looks like:



Source for download: here.

Good luck!

PS: PnP group will finish their new project called - Prism, soon. It is intended to become CAB's replacement in developing LOB applications with WPF. Check for weekly drops here.

DataModel-View-ViewModel in WPF. Part 2 View and ViewModel.

This is the second part on my DataModel-View-ViewModel overview. In the previous part I was talking about DM classes which are intended to supply presentation layer that is composed of the View and ViewModel with data. Let's look at this View and ViewModel.

View

View is just a view (a xaml + codebehind class) and nothing more. It shouldn't keep any state or implement any logic operations except ones that relates to rendering.

VM doesn't "know" the view class and "speaks" with it through the IView interface. As I've mentioned earlier VM doesn't let you to switch UI framework without code review as ViewModel is tightly coupled with WPF-specific entities (such as commands), so for simplicity's sake I've promoted a IWPFView interface that consists of WPF-specific properties and events.



ViewModel

And at last main trinity's player. This class keeps all view related logic and state. My base VM class is parameterized vith view interface and it's descendant is parameterized with DM interface. Using CAB's IoC-container I resolve all of VM dependencies and inject it (VM) into View.


This classes have a bunch of useful virtual methods that are fired when View/DataModel set/unset events happen, in DataModel Loaded/ExceptionCatched events and View's Loaded/Unloaded. In a base class VM sets itself to a view's DataContext property, thus enabling it to update itself by DM, business objects and VM change events catching in databinding. So, speaking in Martin Fowler's words view in WPF is an ActiveView.

You can also find an ActionsViewModel on the diagram above. This class keeps a CommandModel objects list (very useful approach to wrap wpf command from Dan Crevier). For every command VM creates a command binding in a view automaticly.

ViewModel doesn't prohibit you from editing business object supplied by DM in UI and doesn't makes any validations of unedrlying data. So to avoid errors of this kind all of my objects are being edited in wizard UI (I've written a custom WPF control for it. I'll propably write about it later) that tracks object state and avoids saving invalid objects. But if you want to edit objects in your UI in a simple way you propably should read this article from Pete W.

That is all on View and ViewModel. In next part I'll assemble a simple example and (as I promised before) I'll include a sample code.

Good luck!

DataModel-View-ViewModel in WPF. Part 1 DataModel.

All of my UIs are built on very powerful pattern called DataModel-View-ViewModel (DM-V-VM) that was first described by Dan Crevier. I've written a small "framework" (I better say set of classes) to enhance it to my needs.


We have chosen a WPF UI framework in conjuction with the Composite Application Block (CAB) and SmartClient Software Factory (SCSF) to be the foundation of the presentation layer for the project. CAB stimulates and actively using another two UI patterns Model-View-Controller (M-V-C) and Model-View-Presenter (M-V-P). So my set of classes is an extension to an existing infrastracture that uses some of the built-in CAB functionality, especialy IoC-container to resolve dependencies of my classes.

DM-V-VM pattern is a special case of another more brief UI pattern - M-V-P. Martin Fowler calls it the PresentationModel. There is one problem with this pattern - it is fantastic in WPF, but you won't be able to switch to another UI technology without rewriting some code (you can read some on this in Dr.WPF blog). And if it is an evil you can live with than this pattern will be the best choice. And may be it will become too complex to maintain your code when you will have more then 5 data sources. In this case I would recomend you to switch to the M-V-P pattern.

So let's go on.

DataModel(DM)

Classes that provide data (business objects). Their duty is to provide data in WPF-friendly way (at least to implement INotifyPropertyChanged). All the properties and some of methods should only be accessed from UI thread, and it is strongly recommended not to block the UI thread for long.

I think that DM classes (as they were described by Dan Crevier) perfectly fits SOA way of programming, being a data gateway from services to UI.

But services are not the only possible source of data, it can be anything - a file in a file system, for example. To make DM classes lossely-coupled with this different data sources there are providers system that is delegated to obtain data (a strategy by GoF).

A foundation for my DM classes is the Dan Crevier's implementation of DM-V-VM pattern so I shall concentrate on my enhancments instead of rewriting code here.

1. The first thing to come is the base interface for DM classes with the couple of inherited generic interfaces that are narrows (or should I say precises) DM functionality by restricting Entity and Provider types.
   
2. The second thing is the typed provider interface.



3. Base DM class is the third thing. It contains a bunch of asyncronous methods (load complete notification, exception catched notification, etc.) plus a set of virtual methods to be overriden in descendant classes.
   

Invention of generic provider enabled me to write generic DM class that is parameterized with an entity type and typed provider (typed by entity type). I've called it SingleEntityModel. This class frees you from writing lots of DM descendants with the only duty to provide some Entity.

All the clients work with the DM objects through their interfaces as they are treated as a local services and can be injected in dependent code by an IoC-container.

That is all on DataModel, check for new parts.

Good luck!

PS: I will include code in a later parts.

Safe event pattern

I've found this useful little pattern browsing the code of the latest Prism drop.
It looks like this:

public event EventHandler Updated = delegate { };

I've never declared events in my code this way. But using this little pattern you can forget about the tedious safety event raising checks and write like in the following line of code:

Updated(null, new AccountPositionEventArgs());

instead of:

EventHandler handler = Updated;
if (handler != null)
handler(null, new AccountPositionEventArgs());

I'll remember this great stuff.

Good luck!