UnityContainer registers itself!?

If you look at Prism 2.0 (Composite WPF), you will see the old codes have been commented out

// We register the container with an ExternallyControlledLifetimeManager to avoid
// recursive calls if Container.Dispose() is called.
// Container.RegisterInstance<IUnityContainer>(Container);

Base on this post http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=52999, that is because the container’s already registered itself.

The Power Of Model Based Programming

One of the key things when using the Model-View-ViewModel pattern is to understand the patterns, understand the paradigm behind the pattern. A lot of development teams said they understood the pattern (it is just another variation of the classic Model-View-Controller pattern) but they still having trouble to implement the pattern. This post is trying to highlight one of the key concepts that a lot of people are missing, which is the Model base programming. This post is not to explain the Model-View-ViewModel pattern.

Let provide an example to show the different.
1. Requirement
System has a list view and a combo box (see picture below). The list view allows user to select a list of customers that later can be chosen (listed) in the combo box. The list of items in the combo box is dynamically changed.


2. Analysis and Design

2.1   Event based

From the event based point of view, when user checks on a check box, the program should do something, it could be getting the list of selected items from the list box, and then re-populates the list to the combo box?

  • So what happen if we have 2 combo boxes? We just have to populate the second combo box in the event handler…
  • What happen if we need to remove the combo box(es)? We just have to remember to remove the code that populates that control.
  • What happen if we have another screen that can change the selected customers?
  • What happen if we have another screen that consumes the list of selected customers?
  • When we repopulate the list of selected customers, do we have to write custom codes to maintain the selected item in that list?

Looks like we have too many questions

2.2   Model based

By focus on the model, we can say that the combo box and the list view are just 2 different presentations of the model (a list of customers). With that in mind, we can expand this example a bit, instead of the selected customer; we can actually have Good Customers, Bad Customers, Ok Customers…they are just the different presentations of the same model.

No event handlers are needed. And all controls (list view, combo box) are totally independence.

All actions from the user (UI) should be to update (modify) the model (This is why the Model-View-ViewModel and the Command pattern are usually go together, because updating the model should be implemented as a command). The view’s just reflect (or present) the model to the user.

3. Implementation

Below is the XAML for the demo screen, no codes behind are needed!

<window x:Class="FilterSample.Window1"
    Title="Sample" Height="300" Width="300">
    </window><window .Resources>
        <datatemplate x:Key="IsSelectedTemplate">
            <checkbox IsChecked="{Binding Path=IsSelected}" />

        <datatemplate x:Key="SelectedItemTemplate" DataType="{x:Type local:Customer}">
            <textblock Text="{Binding Name}">
                </textblock><textblock .Style>
                        </style><style .Triggers>
                            <datatrigger Binding="{Binding IsSelected}"
                                <setter Property="UIElement.Visibility" Value="Collapsed" />


        <combobox ItemsSource="{x:Static local:ApplicationModel.Customers}" 
                  ItemTemplate="{StaticResource SelectedItemTemplate}" 
                  Height="22" Margin="10"/>

        <listview ItemsSource="{x:Static local:ApplicationModel.Customers}" Margin="10">
            </listview><listview .View>
                    <gridviewcolumn Header="Selected" 
                                    CellTemplate="{StaticResource IsSelectedTemplate}"  />
                    <gridviewcolumn Header="Customer Name" 
                                    DisplayMemberBinding="{Binding Name}" />

4. Conclusion

Clearly, with this model, it requires a total different mindset, a total different paradigm of thinking. For some people, it is not something that can change overnight. So be careful if you want to apply this pattern for your development team.

XAML vs C# (Composite Collection) – repost

Well, there are more than one person asked me the same question related to composite collection so I decided to copy the content from my old blog here
Couple days ago, one of the developer in my team came to me and asked for how to use the CompositionCollection in WPF. We can easily use that in XAML, the code will look something likes

   <collectioncontainer Collection="{x:Static local:ApplicationModel.Projects}"/>
   <collectioncontainer Collection="{x:Static local:ClonedModel.Projects}"/>

But we need to support sorting, grouping…it turns out that what we really need here is a CollectionView on top of the composition collection. (We have been using the pattern called Model-View-ViewModel for a long time). So the solution is the use the same construct as the xaml code above but turn them into C#. The code will look something likes below

CompositeCollection cc = new CompositeCollection();
CollectionContainer c1 =
   new CollectionContainer() { Collection = ApplicationModel.Projects };
CollectionContainer c2 =
   new CollectionContainer() { Collection = ClonedModel.Projects };
ICollectionView cv = ((ICollectionViewFactory)cc).CreateView();

As you can see, the syntax between XAML and C# (3.0) in this case is pretty identical, but from here, we can add support for sorting, grouping or filtering