ASP.NET Error pages

That is interesting that my previous post talked about error pages in and yesterday I got this (see image below) when I tried to access blackberry online shopping site

That is good to know that this website is built using ASP.NET MVC, WCF and a Controller-Service-Repository pattern, so instead of disappointed cause the website crashed, I felt like this is built by some of my “friends” 🙂

PS: the good news is it was fixed right after that!


Reuse is good!

One of the theme that I’ve always seen in design when people try to create some kind of “framework” is the heavily use of inheritance. Because one of the thing that people has been taught is “reuse is good”. Looks at the design below (noted that this design has nothing to do with DDD)

The same design is applied for repositories…

And the only reason to have this kind of design is for reusability, no infrastructure codes can easily deal with IService<T> or any other base classes in this design. (And there is no reason for infrastructure codes to deal with those things)

The next question is what happens if the UserService (or any service class) doesn’t need all functions implemented in the base class? What happens if there are some business rules need to be checked? (Then the workaround is to add more abstract methods around all functions in the base class)

The point here is: There is no reason to create a complex but not very useful design. My preferable design is something likes

We can still reuse some of the codes through composition but not inheritance, there is a well written blog post discuss almost the same issue here

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.