Sharing Common Volatile Assemblies Across Solutions and Teams

 

I've taken over the role of Architect on a large project made of several applications all sharing a lot of common assemblies.

 

The project is composed of several sub teams, every team is responsible for an application and share multiple common assemblies (sort of framework). Because the project is still in an early stage, the common assemblies incurs a lot of modifications on implementation but also on contract level. Therefor common assemblies are generated by custom CI (Continous Integration)builds that drops the assemblies on a network folder.  The developers working on the applications, references the common assemblies through the network folder so that when a new version of the assembly is build, it is automatically refreshed by Visual Studio. 

 

 

 

 

 

This chaotic architecture and wrong way of working brings a lot of trouble. First of all, the developers are not isolated from each others changes. Because the applications are directly referencing the assemblies stored on the network share, every time a CI build generate a new version of the common assemblies - these are automatically picked-up by Visual Studio. When breaking changes are introduced in the common assemblies, dependent applications suddenly breaks.
e.g. -> When the developer A check’s in a file belonging to a shared project this trigger a CI build and refreshes the shared assembly on the build output folder –  Visual Studio of developer B detect that the referenced assembly has changed and refreshes the local bin folder - potentialy breaking the build of B and this without performing a get-latest version.

The teams also experiences a lot of runtime errors caused by not matching assembly manifests. The problem is that the common assemblies are versioned and also dependent on other common assemblies.
 e.g. -> App A depend on Common1-V1 and Common2-V1. Common1-V1 depend on common3-V1 & Common2-V1 depend on Common3-V2. This leads to runtime errors because only 1 assembly version of Common3 can be in the app bin folder at the same time. When the application creates a new instance of Common3 (not the right version) the runtime detect that the assembly manifest of Common3 is different from the expected version and throws a fatal error.

Despite all the pain, the teams didn't want to perform a big architectural refactoring right now – they are behind schedule and needs to release a first version of the applications next month.  So I searched for an efficient way to bring some order in this chaos without impacting the project too much.

The first thing was to change the references in the VS soltions. I created a local “_Reference” folder on the root of every VS solution and copied all tools and shared assemblies into this folder. I deleted and re-created all references so that they now point to the local "_Reference" folder. This improve the build time and isolate the teams from each other changes - but the spaghetti of dependencies was still causing a lot of trouble. The teams still needed to constanly update their local _Reference folder with the latest version of the common assemblies  otherwise they could experience integration issues later on. But copying constantly the common assemblies is error prone and tedious.

For this project automating the syncing of the local references was a must, therfore I made a small tool: JoPack. I grouped the shared assemblies in packages and created a central xml file representing our project catalogue.
The catalogue is basically an xml file defining the packages and the files included in those packages and the path (source) where they can be found. It also describes the dependencies between the packages. I added a local dependency.xml file to each solution root path. This file lists the packages used by a particular solution. The catalogue is versioned on our source controller and available through a network share.

 

Based on the dependency.xml, JoPack synchronizes the local reference folder with the shared files.

 

JoPack download all the packages present in the dependency.xml file but also other packages the root packages are dependent on.
Our shared assemblies listed in the catalog.xml file are still created by CI builds and put on the network shares but now each time a new version of an assembly is created a developer can use JoPack to synchronize his local reference folder. Once the solution is build and all tests are passing the local reference folder can be checked-in making it available to all other developers working on the same application.
We also automated this process by running JoPack as part of our CI build:
We setup a pre-build target that launches JoPack to sync the solution local reference folder on the CI server. When the build succeed the CI build check the _Reference folder back in. Now the developers don’t need to run JoPack on their local machine anymore.

 This strategy decreased the complexity due to the number of dependenices because the number of shared parts went from 100 assemblies to 15 packages. The dependencies are also more obvious because we now dispose of a catalogue that provides an overview of all the dependencies between packages. As only 1 version of a particular assembly can be listed in the catalogue the problem of non matching assembly manifest was also solved.  What was very apreciated by the developers is that the build time decreased drastically and that they didn't experienced suddenly breaking builds anymore.

 

 

Sources, binaries and docs for JoPack can be downloaded here – contribution can be made through the jopack google code repository.

kick it on DotNetKicks.com

New version of the WCFMsmqFactory

Based on the comments I recieved on the article:

Create a WCF service and client, using Msmq, programmatically I've updated the MsmqFactory class.

 

Here is the new version:

using System; using System.Messaging; using System.ServiceModel; using System.ServiceModel.MsmqIntegration;

namespace BelgianAgencies.Wcf
{
    public class WcfMsmqFactory<I>
    {
        private string _queueAddress;
        private string _netmsmqAddress;
        public WcfMsmqFactory(string queueName)
        {
            _queueAddress = String.Format(@".\private$\{0}", queueName);
            _netmsmqAddress = String.Format(@"msmq.formatname:DIRECT=OS:{0}", _queueAddress);
            if (!MessageQueue.Exists(_queueAddress))
                MessageQueue.Create(_queueAddress, true);
        }
        public bool UseCustomDeadLetterQueue
        {
            get;
            set;
        }
        /// <summary>
        /// Is the queue on a device connected to active directory.
        /// Standard = false.
        /// </summary>
        /// <value><c>true</c> if [in active directory]; otherwise, <c>false</c>.</value>
        public bool InActiveDirectory
        {
            get; set;
        }
        public ServiceHost CreateService<T>(string namespaceName)
        {
            var sHost = new ServiceHost(typeof(T));
            MsmqIntegrationBinding binding;
            binding = InActiveDirectory ? new MsmqIntegrationBinding(MsmqIntegrationSecurityMode.Transport) : new MsmqIntegrationBinding(MsmqIntegrationSecurityMode.None);
            // Retry at most 5 times
            binding.ReceiveRetryCount = 1;
            // Max amount of retries before cancel message
            //  (1 + MaxRetryCycles) * (ReceiveRetryCount + 1) = total amount of retries
            binding.MaxRetryCycles = 3;
            // time before timout when unable to get message out of the queue
            binding.ReceiveTimeout = new TimeSpan(0, 0, 5);
            // when unable to dequeue put message on dead letter queue
            //TODO: set to reject on msmq 4.0
            binding.ReceiveErrorHandling = ReceiveErrorHandling.Fault;
            // this message is not volatile, when hard reboot message will not get lost
            binding.Durable = true;
            // timout when opening connection
            binding.OpenTimeout = new TimeSpan(0, 0, 5);
            // timout when closing connection
            binding.CloseTimeout = new TimeSpan(0, 0, 5);
            binding.Namespace = namespaceName;
            sHost.AddServiceEndpoint(
                typeof(I),
                binding,
                new Uri(_netmsmqAddress)
                             );
            return sHost;
        }
        public I CreateChannel()
        {
            var binding = new MsmqIntegrationBinding(MsmqIntegrationSecurityMode.None);
            var address = new EndpointAddress(String.Format("msmq.formatname:DIRECT=OS:{0}", _queueAddress));
            var channelFactory = new ChannelFactory<I>(binding, address);
            return channelFactory.CreateChannel();
        }
    } 
}

.Net Interview questions

This morning a colleague of mine asked me for a list of questions to prepare for a .Net technical interview.

I thought it would be useful to share this list with everyone.

A) Developer

 

1) OO

  • Explain principles of Object Orientation?
  • Can you use abstract classes in place of Inheritance ? What are the differences between these two concepts?
  • Explain polymorphism and write an example in code (C#).

2) Patterns

  • What are Patterns?
  • List some patterns you’ve already used.
  • Explicit one pattern by writing a small example.
  • Explain following patterns: Repository, Factory, Root Aggregate.

3) UML

  • What are the most useful UML diagrams? (list & explain at least 5) .

4) Net & C#

  • What is .Net? (Managed Code - CLR - Runtime) ?
  • Explain concepts as JIT, CLR, GAC, GC?
  • Explain series of processing steps an ASP.NET page goes through (= page lifecycle of ASP.NET) ?
  • Explain following c# keywords: Static, ReadOnly, Const?
  • What is: a Webservice,WCF, WPF, Silverlight and how do these technologies/concepts relate to each other?

5) DB

  • Write simple query that joins 2 tables via a 1-to-N relation that contains a filter and a group by clause.
  • Explain what is a Transaction.
  • What are the properties of a transaction (-> ACID)
  • Explain concepts as Primary Key & Clustered Index and how these concepts relates?
  • Is a GUID a good Clustered index, explain why?

 

B) Architect

  • List and explains the Enterprise Integration patterns, provide advantage/inconvenient for each of them? ->(Primary integration patterns: Database, WebServices, Messaging)
  • What are non functional requirements, provide some examples (e.g. Accessibility, Availability, Security…)?
  • Explain concept Authentication/Authorization how does these concept relates?
  • What is Asynchronous Messaging - what type of infra do you need to set it up?
  • Explain – what is an ESB?
  • What is SOA & list and explain SOA Tenets?

 

C) Senior Developer / Team Lead

  • What is IOC - What is the Goal - which frameworks do you know?
  • Explain what are Unit tests and Integration tests, what differentiate these two types of tests?
  • Provide a small list of programming practices that you would enforce/setup in your dev team?
  • What is Waterfall/Prince2/RUP/Agile/XP/Scrum - how does these concepts relates ?
  • What is DDD?

 

 

 

Some other useful/funny resources:

 

 

 

Prism Walkthrough Part 4: Use Delegate Commands

The final source code can be downloaded here!

In this post we’ll bind a Command to our Menu so that it’s able to add views to the MainRegion.

Create a MenuViewModel:

 

 

Insert following code into the MenuViewModel:

 
   1:  public class MenuViewModel
   2:  {
   3:      private readonly IRegionManager _regionManager;
   4:      private readonly IUnityContainer _container;
   5:   
   6:      public MenuViewModel(IRegionManager regionManager, IUnityContainer container)
   7:      {
   8:          this._regionManager = regionManager;
   9:          this._container = container;
  10:      }
  11:  }

 

Here we created our first ViewModel that will be the target of our View binding.   Our View reference our ViewModel but the ViewModel does not need a reference to a view. The view binds to properties on a ViewModel, which, in turn, exposes data contained in model objects and other state specific to the view. The bindings between view and ViewModel are simple to construct because a ViewModel object is set as the DataContext of a view. If property values in the ViewModel change, those new values automatically propagate to the view via data binding. 

 

When implementing MVVM you need to bind the View and ViewModel, therefore you have the choice between several options.  You can declare the ViewModel as a resource in your view xaml, you can also use  a presenter class that is responsible to instantiate and bind the View to the ViewModel.  This strategy is useful when you need to bind different Views to the same ViewModel.  Because we don’t need this flexibility here we chooses for a simpler design; here it’s the view itself that instantiate and bind to his ViewModel.  Some could claim that I’m not implementing the pure MVVM pattern as in this application the View knows his ViewModel.  I nevertheless chooses for this approach because it’s the simplest way to implement MVVM and also because it enable me to handle UI events like KeyboardPress events gracefully  (see folowing post). 

 

In this design, the ViewModel, never the View, performs all modifications made to the model data. The ViewModel and model are unaware of the View but the View reference his ViewModel.  This design still provide loose coupling in the sence that the ViewModel does not know about the View but it makes some concessions to the purity of MVVM.  Nevertheless these concessions pays dividends in many ways, as you will see in the next series.

 

To setup this binding update the MenuView class:

 

   1:  public partial class MenuView : UserControl
   2:  {
   3:      public MenuView(IRegionManager regionManager,IUnityContainer container)
   4:      {
   5:          InitializeComponent();
   6:          this.DataContext = new MenuViewModel(regionManager, container);
   7:      }
   8:   
   9:      public MenuViewModel ViewModel
  10:      {
  11:          get
  12:          {
  13:              return this.DataContext as MenuViewModel;
  14:          }
  15:      }
  16:  }

 

When the user clicks a MenuItem in the MenuView, a command on the MenuViewModel should execute to display a view in the MainRegion (see line 36 - MenuViewModel).   Here we use the Prism DelegateCommand to implement the Command pattern. 

 

To retrieve the right View we choose for convention over configuration.  The  LoadViewCommand takes a parameter that is the the name of the View without the suffix View. 

The ViewModel has exactly the same name as the View but ends with ViewModel ->see MenuViewModel line 39.

To implement this convention we need to register the Views with a name parameter via the Unity container in the Module Initialization –> see Coremodule line 8 & 9.

 

Add the following code to the CoreModule.cs:

 

   1:  public void Initialize()
   2:  {
   3:      this.RegisterViewsWithRegions();
   4:  }
   5:   
   6:  protected virtual void RegisterViewsWithRegions()
   7:  {
   8:      this.regionManager.RegisterViewWithRegion(RegionNames.MenuRegion, typeof(MenuView));
   9:      this.regionManager.RegisterViewWithRegion(RegionNames.StatusbarRegion, typeof(StatusbarView));
  10:  }

 


Update the MenuViewModel:

 

   1:  public class MenuViewModel : INotifyPropertyChanged
   2:  {
   3:      private readonly IRegionManager _regionManager;
   4:      private readonly IUnityContainer _container;
   5:          
   6:      public MenuViewModel(IRegionManager regionManager,IUnityContainer container)
   7:      {
   8:          this._regionManager = regionManager;
   9:          this._container = container;
  10:          this.LoadViewCommand = new DelegateCommand<object>(this.LoadView, this.CanLoad);
  11:              
  12:      }
  13:   
  14:      #region PropertyChanged
  15:      public event PropertyChangedEventHandler PropertyChanged;
  16:          
  17:      private void OnPropertyChanged(string propertyName)
  18:      {
  19:          PropertyChangedEventHandler handler = this.PropertyChanged;
  20:          if (handler != null)
  21:          {
  22:              handler(this, new PropertyChangedEventArgs(propertyName));
  23:          }
  24:      }
  25:      #endregion
  26:   
  27:      #region LoadViewCommand
  28:      public DelegateCommand<object> LoadViewCommand { get; private set; }
  29:      public event EventHandler<DataEventArgs<string>> LoadedView;
  30:   
  31:      private bool CanLoad(object arg)
  32:      {
  33:          return true;
  34:      }
  35:          
  36:      private void LoadView(object obj)
  37:      {
  38:          IRegion mainRegion = this._regionManager.Regions[RegionNames.MainRegion];
  39:          string viewName = obj.ToString() + "View";
  40:          var view = this._container.Resolve<IView>(viewName);
  41:          mainRegion.Add(view,viewName);
  42:          mainRegion.Activate(view);
  43:          this.OnLoadView(new DataEventArgs<string>(obj.ToString()));
  44:      }
  45:   
  46:      private void OnLoadView(DataEventArgs<string> e)
  47:      {
  48:          EventHandler<DataEventArgs<string>> loadHandler = this.LoadedView;
  49:          if (loadHandler != null)
  50:          {
  51:              loadHandler(this, e);
  52:          }
  53:      }
  54:      #endregion
  55:  }

 

Bind the LoadViewCommand in our MenuItem.xaml:

 

   1:  <Menu Name="menu1">
   2:      <MenuItem Header="File">
   3:          <MenuItem Header="New"  CommandParameter="CreateFile" Command="{Binding Path=LoadViewCommand}"/>
   4:          <MenuItem Header="Folder"  CommandParameter="CreateFolder" Command="{Binding Path=LoadViewCommand}" />
   5:      </MenuItem>
   6:  </Menu>

 

 

 

You should be able to run the application and when you click the menu File, you should see :

 

 

 

This end the Walkthrough series.  In these 4 parts we setup the foundation of our client application implementing the MVVM pattern and learned how to use Prism to create a modular architecture.  

 

In the following posts I’ll provide a complete application build on the architecture described in part 0 -> (WPF/WCF/EntityFramework).   The application extends this basic design and provide an example on how to use the asynchronous behavior of web services to create responsive applications.

 

 

kick it on DotNetKicks.com

Prism Walkthrough - Part 3: Add Views to Regions

Source code of this part can be downloaded here.

In this part we’ll create our first views and display them inside their regions.  The views are the controls that display our content.  Because our application is build with modularity in mind it’s the Module and not the Shell that should define which views need to be added to the regions. 

 

 

1) We add a folder “Views” to our Module project and 4 views inside this new folder: 

  • CreateFileView:  One of the views that can be displayed in the MainRegion
  • CreatFolderView: Another view for the MainRegion
  • MenuView: Control that will be responsible to Add views to the MainRegion
  • StatusBar: Control that will be added to the StatusBarRegion

 

 

To add views to our regions we use the prism region manager service.  The region manager service is responsible for maintaining a collection of regions and creating new regions for controls.  Typically, we interact directly with region manager service to locate regions in a decoupled way through their name and add views to those regions. By default, the UnityBootstrapper base class registers an instance of this service in the application container. This means that we can obtain a reference to the region manager service in our application by using dependency injection.

We use constructor dependency injection to gather an instance of the RegionManager and store it in a local field and it’s  in the Initialize method of our CoreModule class that we implement logic to add the initial views to our Regions. 

 

2) Modify the CoreModule class like:

   1:  public class CoreModule : IModule
   2:  {
   3:      private readonly IRegionManager regionManager;
   4:   
   5:      public CoreModule(IRegionManager regionManager)
   6:      {
   7:          this.regionManager = regionManager;
   8:      }
   9:   
  10:      public void Initialize()
  11:      {
  12:          this.RegisterViewsWithRegions();
  13:      }
  14:   
  15:      protected virtual void RegisterViewsWithRegions()
  16:      {
  17:          this.regionManager.RegisterViewWithRegion(RegionNames.MenuRegion, typeof(MenuView));
  18:          this.regionManager.RegisterViewWithRegion(RegionNames.StatusbarRegion, typeof(StatusbarView));
  19:      }
  20:  }

 

 

To overcome magic constants in our code  we used a class containing all our region names.

 

3) Add this RegionNames class to your Infrastructure Library:

   1:  namespace PrismWalkthrough.Infrastructure
   2:  {
   3:      public class RegionNames
   4:      {
   5:          public const string MainRegion = "MainRegion";
   6:          public const string MenuRegion = "MenuRegion";
   7:          public const string StatusbarRegion = "StatusbarRegion";
   8:      }
   9:  }

 

 

Finally to see something displayed in our Menu and StatusBar we need to add some content inside these controls:

 

4) Modify the MenuView.xaml:

<StackPanel>
    <Menu Name="menu1" Background="Transparent" >
        <MenuItem Header="File" >
            <MenuItem Header="New"  CommandParameter="CreateFile" />
            <MenuItem Header="Folder" CommandParameter="CreateFolder"  />
        </MenuItem>
    </Menu>
</StackPanel>

 

5) Modify the StatusBarView.xaml:

<Grid>
    <TextBlock Text="This is the StatusBar" />
</Grid>

 

When pressing F5 you should see:

 

 

kick it on DotNetKicks.com

Prism Walkthrough - Part 2: Define The Regions

Define the Regions

 

Our shell will contain 3 regions:

  • Menu Region: contain a Menu that is responsible to load views in the Main Region
  • Main Region: region that will load the workspace controls – these are the views that will handle the application features. In our application only one view at a time can be loaded in the Main Region.
  • Status Bar Region: provide info about current application state 

 

These regions are the placeholders for the controls defined in our Modules.  Our application will contain only one Module: the CoreModule but this application can easily be extended by adding new modules.   In our application the regions are defined as ItemsControls  in the Shell.xaml file and can be accessed in a decoupled way by their names; they support dynamically adding or removing views at run time.

  1. To add the regions in the Shell window add the following namespace definition to the root Window element. You need this namespace to use an attached property for regions that is defined in the Composite Application Library:  xmlns:cal=http://www.codeplex.com/CompositeWPF.
  2. Replace the Grid in the Shell by the following xaml:
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="35" />
            <RowDefinition Height="*" />
            <RowDefinition Height="35" />
        </Grid.RowDefinitions>
        <ItemsControl Name="MenuRegion" cal:RegionManager.RegionName="MenuRegion" 
    VerticalAlignment="Top" Grid.RowSpan="2" Height="26" HorizontalAlignment="Left" Background="Transparent" Margin="0,12,0,0"/>
    <Grid Margin="4,4,4,4" Grid.Row="1"> <Border Background="GhostWhite" BorderBrush="LightGray"
    BorderThickness="1" CornerRadius="5" Margin="0,0,0,0"> <ItemsControl Name="MainRegion"
    cal:RegionManager.RegionName="MainRegion" Margin="4" Height="291" />
    </Border> </Grid> <Border Grid.Row="2" > <ItemsControl Name="StatusbarRegion"
    cal:RegionManager.RegionName="StatusbarRegion" Background="Transparent" />
    </Border> </Grid>

 

Now you should be able to run the application and see this screen:

 

 

Next --->

kick it on DotNetKicks.com

 

 

 

 

Prism walkthrough - Part 1: Create The Shell

 

The client side application is made out of three assemblies:

  • The Shell (PrismWalkthrough.Shell)
  • The Modules ( PrismWalkthrough.Modules)
  • The Infrastructure (PrismWalkthrough.Infrastructure)

The foundation of the application is “The Shell”.  The Shell is the top-level window of an application based on the Prism Composite Application Library. This window is a place to host different user interface (UI) components that exposes a way for itself to be dynamically populated by others, and it may also contain common UI elements, such as menus and toolbars. The Shell window sets the overall appearance of the application.

 

In our application it’s the shell that is responsible to load the Modules. A module represents a set of related concerns. It can include components such as views, business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion.  In this walkthrough our application will contain only one module: the CoreModule nevertheless the modular architecture enable us to easily extend the application adding new modules later on.

 

The Infrastructure Assembly is a shared library referenced by both the shell project and the module projects, and holds shared types such as constants, event types, entity definitions and interfaces.

 

Create the Solution

 

  1. Create the Shell project (PrismWalkthrough.Shell) application with Visual Studio-> File, Project, WPF Application.
  2. Add the Modules project and Infrastructure project –> File, Add New Project, Classlibrary
  3. The three projects should reference the Composite Application Library assemblies, add the following reference:
    (These assemblies can be found in the october 2009 Guidance of Prism -  you will need to compile the sample application)
    1.  
      • Microsoft.Practices.Composite.dll
      • Microsoft.Practices.Composite.Presentation.dll
      • Microsoft.Practices.Composite.UnityExtensions.dll
      • Microsoft.Practices.Unity.dll
      • Microsoft.Practices.ServiceLocation.dll
  4. Add a reference to the Modules and Shell projects referencing the Infrastructure assembly.
  5. Add a refrence to the Shell project referencing the Modules assembly.
  6. Add a refrence to the Modules and infrastructure that reference to the WindowsBase & PresentationCore and PresentationFramework –> Reference, Add, .Net tab.

 

Your solution should look like this:

 

 

 

 

Initialize the application

To enable modularity and dependency injection in our application we need to make some changes to the standard WPF application we just created.  First we setup a bootstrapper.  The bootstrapper is responsible for the initialization of the application, this is realized by overriding the CreateShell method.

  1. Add a new class on the root of the application containing the shell (PrismWalkthrough.Shell), name it Bootstrapper
  2. The Bootstrapper should inherit from Microsoft.Practices.Composite.UnityExtensions.UnityBootstrapper class and override the CreateShell method. You need to instantiate the Shell through the Unity conatiner and call his Show method
   1:  public class Bootstrapper : UnityBootstrapper
   2:  {
   3:      protected override System.Windows.DependencyObject CreateShell()
   4:      {
   5:          Shell shell = this.Container.Resolve<Shell>();
   6:          shell.Show();
   7:          return shell;
   8:      }
   9:  }

 

To be able to run the bootstrapper at least one module should be registered in our application. 

  1. Add a class to the PrismWalkthrough.Module and name it CoreModule.cs
  2. This class should implement the IModule interface:
   1:  namespace PrismWalkthrough.Modules
   2:  {
   3:      public class CoreModule : IModule
   4:      {
   5:          public void Initialize()
   6:          {
   7:              
   8:          }
   9:      }
  10:  }

 

Through the bootstrapper you must configure which Modules are available in our Shell. You need to register at least one module in your bootstrapper.

  1. Override the InitializeModules in the bootstrapper:
   1:  protected override void  InitializeModules()
   2:  {
   3:      IModule coreModule = this.Container.Resolve<CoreModule>();
   4:      coreModule.Initialize();
   5:  }

 

The WPF Application class needs to execute the bootstrapper by calling his Run method. 

  1. First you should delete the StartupUri in the App.Xaml file.
    <Application x:Class="PrismWalkthrough.Shell.App"
                 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    </Application>
  2. Override the OnStartup method in the App.cs file:
   1:  protected override void OnStartup(StartupEventArgs e)
   2:  {
   3:      base.OnStartup(e);
   4:      Bootstrapper bootstrapper = new Bootstrapper();
   5:      bootstrapper.Run();
   6:  }

 

Now you should be able to run you application, you should see a white screen.

Next --->

 

Create a refrence WPF application using MVVM with Prism, WCF and Entity Framework

In this series of posts I’ll build a reference WPF application(template) that can be used as a template for line of business applications (LOB). . This series will take the form of a walkthrough providing an introduction to the development of a Windows Presentation Foundation (WPF) application with Prism using the MVVM (Model View ViewModel) that includes the elements that are common to most WPF applications.

 

This walkthrough guides you through the development of a WPF/Prism desktop application using the following steps:

 

  • Defining the application architecture. 
  • Creating the Shell with his Regions Loading our Core Module.
  • Use styles to create a consistent appearance.
  • Use the Command pattern.
  • Using Unity as IOC.
  • Setting up the infrastructure for MVVM.
  • Use WCF to setup our Service Layer.
  • Use the Entity Framework as DAL.

 

Prerequisites

 

Part 0: Defining the application architecture

 

This application will be build using a Rich Internet Application Architecture (RIA). This architecture type uses a Web infrastructure that combined with a client-side application that handles the presentation. The Web infrastructure will be build using WCF and the client-side application will be build with WPF.

 

The client side application will use Prism for extensibility and to get the basic infrastructure for applying MVVM pattern.   This application will be composed of the following components:

 

  • The shell: the main window that is responsible to load all other modules.
  • The core module: contains the basic components to enable the basic functionalities of the application.

By dividing our client application in these two components we make our application ready to be extended; we will be able to add new features without touching to the code of the core module.

The WCF application is composed of several layers:

  • The service layer containing the message types.
  • The business layer contains business logic.
  • The data layer contains data access components.

 

The data layer will use the Entity Framework 2.0 to interact with the DB.

 

To be continued --->

kick it on DotNetKicks.com

Anti-Pattern 5: Fat UI's

One of the major flaws in an un-testable design is the very tight coupling between the UI and the actual domain and/or presentation logic. Our typical ASP.NET applications are difficult to test, because much of the logic is contained within the codebehind files, which derive from Web.UI.Page, which needs an HttpContext, which is difficult to mock. Furthermore, the output of the methods in the codebehind is often not easily-testable, because it's a side-effect (such as calling DataBind() on a GridView).

This same problem exists in windows forms: How do you test the logic inside the form when you are unable to control the input & output of the UI? Let’s examine the following code sample.

   1:  public partial class LoginForm : Form
   2:  {
   3:      const string AUTHNETICATION_FAILED = "Authentication failed!";
   4:      public LoginForm()
   5:      {
   6:          InitializeComponent();
   7:      }
   8:   
   9:      private void LoginButton_Click(object sender, EventArgs e)
  10:      {
  11:          var membershipService = new MembershipService();
  12:          
  13:          if (membershipService.Authenticate(
  14:                                   UserNameText.Text,   
  15:                                   PasswordText.Text
  16:                                   )
  17:                )
  18:          {
  19:              MainForm form = new MainForm();
  20:              this.Hide();
  21:              form.Show();        
  22:          }
  23:          else
  24:          {
  25:              MessageLabel.Text = AUTHNETICATION_FAILED; 
  26:          }
  27:      }
  28:  }

 

Apart from being a pretty naïve implementation of a login form, this code is also hard to test. It’s design contains several smells of un-testable design. First of all it instantiates his Services directly, making it impossible to inject his dependencies through test doubles. Another problem is how can we test that; when the authentication was successful, the MainForm is shown?

By applying what we learned earlier we could already make our SUT more testable:

   1:  public partial class LoginForm : Form
   2:  {
   3:      const string AUTHENTICATION_FAILED = "Authentication failed!";
   4:      private IMembershipService _membershipService;
   5:      private INavigationService _navigationService;
   6:   
   7:      public LoginForm()
   8:      {
   9:          InitializeComponent();
  10:          _membershipService = new MembershipService();
  11:          _navigationService = new NavigationService(this);
  12:      }
  13:   
  14:      public LoginForm(
  15:          IMembershipService membershipService, 
  16:          INavigationService navigationService
  17:          )  //This constructor is only for testing purposes
  18:      {
  19:          _membershipService = membershipService;
  20:          _navigationService = navigationService;
  21:      }
  22:   
  23:      public void LoginButton_Click(object sender, EventArgs e)
  24:      {
  25:          if (_membershipService.Authenticate(
  26:              UserNameText.Text, 
  27:              PasswordText.Text)
  28:             )
  29:          {
  30:              _navigationService.NavigateTo(new MainForm());
  31:          }
  32:          else
  33:          {
  34:              MessageLabel.Text = AUTHENTICATION_FAILED; 
  35:          }
  36:      }
  37:  }
  38:   
  39:  public interface INavigationService
  40:  {
  41:      void NavigateTo(Form focusForm);
  42:  }
  43:   
  44:  public class NavigationService : INavigationService
  45:  {
  46:      private Form _form;
  47:      public NavigationService(Form form)
  48:      {
  49:          _form = form;
  50:      }
  51:   
  52:      public void NavigateTo(Form focusForm)
  53:      {
  54:          _form.Hide();
  55:          focusForm.Show();
  56:      }
  57:  }

 

Here we encapsulated the Navigation logic into a Service and we’ve created a specific constructor that can be used by our tests to inject a test double making possible to write the following test:

   1:  [Test]
   2:  public void LoginButton_Click_OnSuccessfullLogin_ShouldNavigateToMainForm()
   3:  {
   4:      //Arrange
   5:      var mocks = new MockRepository();
   6:      var membershipServiceMock = mocks.StrictMock<IMembershipService>();
   7:      var navigationServiceMock = mocks.StrictMock<INavigationService>();
   8:      var form = new LoginForm(membershipServiceMock,navigationServiceMock);
   9:   
  10:      Expect.Call(membershipServiceMock.Authenticate(null, null)).Return(true);
  11:      navigationServiceMock.NavigateTo(null);
  12:      LastCall.IgnoreArguments();
  13:      mocks.ReplayAll();
  14:   
  15:      //Act
  16:      form.LoginButton_Click(null,null);
  17:   
  18:      //Assert
  19:      mocks.VerifyAll();
  20:  }

 

By applying one of the variants of the MVC pattern namely the PresentationModel we can completely decouple the presentation logic from infrastructure and test it in isolation:

   1:  public interface ILoginFormView
   2:  {
   3:      string UserName { get; set; }
   4:      string Password { get; set; }
   5:      string Message { get; set; }
   6:   
   7:      void NavigateTo(Form focusForm);
   8:  }
   9:   
  10:  public interface IMembershipService
  11:  {
  12:      bool Authenticate(string userName, string password);
  13:  }
  14:   
  15:  public class LoginFormPresenter
  16:  {
  17:      const string AuthneticationFailedMessage = "Authentication failed!";
  18:      private readonly ILoginFormView _view;
  19:      private readonly IMembershipService _membershipService;
  20:   
  21:      public LoginFormPresenter(ILoginFormView view, IMembershipService membershipService)
  22:      {
  23:          _view = view;
  24:          _membershipService = membershipService;
  25:      }
  26:   
  27:      public void LoginButtonClick()
  28:      {
  29:   
  30:          if (_membershipService.Authenticate(
  31:                      _view.UserName,
  32:                      _view.Password
  33:                      )
  34:              )
  35:          {
  36:              _view.NavigateTo(new MainForm());
  37:          }
  38:          else
  39:          {
  40:              _view.Message = AuthneticationFailedMessage;
  41:          }
  42:      }
  43:   
  44:  }
  45:   
  46:  public partial class LoginForm : Form, ILoginFormView 
  47:  {
  48:      private LoginFormPresenter _presenter;
  49:   
  50:      public string UserName
  51:      {
  52:          get
  53:          {
  54:              return UserNameTextBox.Text;
  55:          }
  56:          set
  57:          {
  58:              UserNameTextBox.Text = value;
  59:          }
  60:      }
  61:   
  62:      public string Password
  63:      {
  64:          get
  65:          {
  66:              return PasswordTextBox.Text;
  67:          }
  68:          set
  69:          {
  70:              PasswordTextBox.Text = value;
  71:          }
  72:      }
  73:   
  74:      public string Message
  75:      {
  76:          get
  77:          {
  78:              return MessageLabel.Text;
  79:          }
  80:          set
  81:          {
  82:              MessageLabel.Text = value;
  83:          }
  84:      }
  85:   
  86:      public LoginForm()
  87:      {
  88:          InitializeComponent();
  89:          _presenter = new LoginFormPresenter(this, new MembershipService());
  90:      }
  91:   
  92:      public void LoginButton_Click(object sender, EventArgs e)
  93:      {
  94:         _presenter.LoginButtonClick();
  95:      }
  96:   
  97:      public void NavigateTo(Form focussedForm)
  98:      {
  99:          Hide();
 100:          focussedForm.Show();
 101:      }
 102:  }
 

We are now able to test the presentation logic:

   1:  [TestFixture]
   2:  public class LoginFormPresenterTest
   3:  {
   4:      const string UserName = "myUserName";
   5:      const string Password = "myPassword";
   6:   
   7:      [Test]
   8:      public void LoginButtonClick_AuthenticationSuccess_ViewShouldNavigateToMainForm()
   9:      {
  10:          //Arrange
  11:          var viewMock = CreateLoginFormViewStub();
  12:          var membershipServiceMock = CreateMembershipServiceMock(true);
  13:          var subject = new LoginFormPresenter(viewMock, membershipServiceMock);
  14:   
  15:          //Act
  16:          subject.LoginButtonClick();
  17:   
  18:          //Assert
  19:          viewMock.AssertWasCalled(
  20:              s => s.NavigateTo(null),
  21:              options => options.IgnoreArguments()
  22:              );
  23:      }
  24:   
  25:      [Test]
  26:      public void LoginButtonClick_AuthenticationFailed_ViewMessageIsAuthenticationfailed()
  27:      {
  28:          //Arrange
  29:          var viewMock = CreateLoginFormViewStub();
  30:          var membershipServiceMock = CreateMembershipServiceMock(false);
  31:          var subject = new LoginFormPresenter(
  32:                            viewMock,
  33:                            membershipServiceMock
  34:                            );
  35:   
  36:          //Act
  37:          subject.LoginButtonClick();
  38:   
  39:          //Assert
  40:          Assert.AreEqual("Authentication failed!", viewMock.Message);
  41:      }
  42:   
  43:      private IMembershipService CreateMembershipServiceMock(bool expectedResult)
  44:      {
  45:          var membershipServiceMock = MockRepository.GenerateStub<IMembershipService>();
  46:          membershipServiceMock.Stub(m => m.Authenticate(UserName, Password)).Return(expectedResult);
  47:          return membershipServiceMock;
  48:      }
  49:   
  50:      private ILoginFormView CreateLoginFormViewStub()
  51:      {
  52:          var viewMock = MockRepository.GenerateStub<ILoginFormView>();
  53:          viewMock.UserName = UserName;
  54:          viewMock.Password = Password;
  55:          return viewMock;
  56:      }
  57:  }

 

When designing UI’s you should make your choice between patterns like MVC/MVP/MVVM and use the most appropriate pattern and/or framework for your project.  With the appropriate design a lot of the presentation logic encapsulated into the UI can be extracted and tested. In this example we extracted all the presentation logic encapsulated in our form and transferred it into a presenter. This presenter is completely decoupled from any infrastructure and we are able to easily obtain 100% test coverage with it. The LoginForm itself remains un-testable but it does not contain any logic anymore. His only purpose is to act as a sort of proxy between the windows forms infrastructure and our presentation logic.

 

kick it on DotNetKicks.com

Anti-Pattern 4: Using Global State

Let’s imagine we want to add caching capabilities for our InvoiceRepository class.

 

public class InvoiceRepository
{
    private IDataLayer _db;
    public InvoiceRepository(IDataLayer db)
    {
        _db = db;
    }
    public Invoice GetInvoice(int clientID)
    {
        Cache cache = Cache.GetInstance();
        string key = "Invoice" + clientID.ToString();
        if (cache[key]==null)
        {
            MeteringValues[] dailyValues = _db.GetMeteringValues(clientID);
            int offPeakPrice = _db.GetOffPeakPrice();
            int peakPrice = _db.GetPeakPrice();
            int advances = _db.GetAdvances(clientID);
            cache.Add(key, new Invoice(dailyValues, offPeakPrice, peakPrice, advances));
        }
        return (Invoice)cache[key];
    }
}

In this example we reach into the global state of our InvoiceRepository class and get a hold of the Cache singleton (Cache.GetInstance()). Global variables often show up as instances of the singleton pattern or just as static data in classes.

Not all singletons are bad design but all of them are suspect, presumed guilty until proven innocent! Nevertheless singletons which do not affect the functional behaviour of an application, can behave well as internal dependencies. A good example is the use of the singleton pattern for caching. Using the singleton pattern to implement caching is a valid strategy. The example here above illustrate this strategy nevertheless this example has a big flaw! The flaw is that we can’t intercept the call Cache.GetInstance. We can’t use a mocking framework to replace the Cache.GetInstance as this is a static method and static methods can’t be mocked (with Rhino Mock).

To solve this issue we need to extract the global state out of our Domain Object. We could for example pass a “Cache” object into the constructor:

public InvoiceRepository(IDataLayer db, ICache cache)

But imagine what would happen if we also want to log our exceptions and operations this would result in the following signature:

public InvoiceRepository(IDataLayer db, ICache cache, ILogger log)

 

When using the dependancy injection pattern (through constructor injection) every dependency to a service will result in a parameter we need to pass in our constructor.  That's why when we have a lot of dependencies (and usually we do)  using denpendancy injection result in classes that are difficult to instantiate because we need to inject all  cross cutting concerns (the cache, the logger, …) via the constructor. To solve this issue we can use the factory pattern. Nevertheless the Factory itself is still in his own way making our code more complex. This is why most of Unit test addicts advocates the use of IOC containers like Structuremap or Unity

Using an IOC container our code would look like this:

public class InvoiceRepository
{
    private IDataLayer _db;
    private ICache _cache;
    public InvoiceRepository()
    {
        _db = ObjectFactory.GetInstance<IDataLayer>();;
        _cache = ObjectFactory.GetInstance<ICache>();
    }
}

To test our SUT we can easily configure our container during the Arrange part of our unit test and don’t need to pass these dependencies through the constructor:

//Arrange
myIOCContainer.ForRequestedType<ICache>.TheDefaultIs<StubedCache>();


kick it on DotNetKicks.com