Raffaeu Bermuda Blog

Inversion of Control with NET Framework.

Raffaeu — Tue, 07 Jul 2009 21:10:00 GMT

Today I want to break-out my series of posts about WPF to talk about an interesting design pattern. The Inversion of Control or Dependency Injection. You can find a clear definition at this address: Martin Fowler.

What is it the Dependency Injection?

The dependency injection is a way to inject some information and configuration inside an object, from another one. In this way we keep our object abstract and recyclable.

As you can see in this example, we have two concrete tasks, and each one has an execute command that is exposed by the interface IBaseTask. This will be our bridge from the interface and the concrete implementation.

Manually Dependency Injection.

Now, if we would like to run our example, manually, we should write something like this code:

  1: IBaseTask firstTask = new RunTask();
  2: firstTask.Execute();
  3: IBaseTask secondTask = new WalkTask();
  4: secondTask.Execute();

And the code in each task should be something like that:

  1: public class WalkTask : IBaseTask {
  2:     #region IBaseTask Members
  3: 
  4:     public string TaskName {
  5:         get;
  6:         set;
  7:     }
  8: 
  9:     public void Execute() {
 10:         Console.WriteLine("I am a Walk task");
 11:     }
 12: 
 13:     #endregion
 14: }
 15:

Microsoft Unity for Dependency Injection.

Microsoft Unity is an open source project done by the Microsoft patterns and practice. It can be downloaded here: http://unity.codeplex.com/ and the actual version is the 1.2 present also in the enterprise library 4.1

After you install it, you will have a folder with some .dlls that you have to reference into your solution.

Now let’s go back to our project and let’s change the code in order to have Unity and not a concrete implementation of our interface.

  1: //Unity container
  2: IUnityContainer container = new UnityContainer();
  3: //Type association
  4: container.RegisterType<IBaseTask, WalkTask>();
  5: IBaseTask firstTask = container.Resolve<IBaseTask>();
  6: firstTask.Execute();
  7:

This is the first step, but as you can notice, it’s not so far from a concrete implementation. I mean, in this way we still have to procedural declare the type we want to convert to our interface.

The next step will be to remove the type association and use a configuration file. First of all we need to declare in our app.config file the unity section:

  1: <?xml version="1.0" encoding="utf-8" ?>
  2: <configuration>
  3:   <configSections>
  4:     <section name="Unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, 
  5:              Microsoft.Practices.Unity.Configuration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
  6:   </configSections>

Then we need to associate some type to our container. This is easy.

  1:   <Unity>
  2:     <typeAliases>
  3:       <!-- Lifetime manager types -->
  4:       <typeAlias alias="singleton"
  5:            type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager,
  6:                Microsoft.Practices.Unity" />
  7:       <typeAlias alias="external"
  8:            type="Microsoft.Practices.Unity.ExternallyControlledLifetimeManager,
  9:                Microsoft.Practices.Unity" />
 10:       <!-- Custom types -->
 11:       <typeAlias alias="myInterface" type="InversionOfControl.Model.IBaseTask, InversionOfControl" />
 12:     </typeAliases>

As you can see at the end, we are going to declare our IBaseTask interface. Remember always to declare the complete path otherwise Unity will search the class into the Unity namespace!!

Now let’s build a couple of custom map inside the XML file:

  1:     <containers>
  2:       <container name="firstContainer">
  3:         <types>
  4:           <type type="myInterface" mapTo="InversionOfControl.Model.RunTask, InversionOfControl" name="RunMapping" />
  5:           <type type="myInterface" mapTo="InversionOfControl.Model.WalkTask, InversionOfControl" name="WalkMapping" />
  6:         </types>
  7:       </container>
  8:     </containers>
  9:   </Unity>
 10: </configuration>

As you can see, we are using our Alias to declare the interface and then we are giving a custom name the our mapping. Now we can go back to our code and do some fancy operations.

Declare the configuration section and initialize the container:

  1: IUnityContainer container = new UnityContainer();
  2: UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("Unity");
  3: section.Containers["firstContainer"].Configure(container);
  4:

Then let’s Inject a couple of objects inside our interface:

  1: IBaseTask firstTask = 
  2:    container.Resolve<IBaseTask>("RunMapping");
  3: firstTask.Execute();
  4: IBaseTask secondTask = 
  5:    container.Resolve<IBaseTask>("WalkMapping");
  6: secondTask.Execute();

Very easy right? In our example we are going to write in a procedural way which mapping we want to use, but of course this information should be retrieved at run-time from a Database or a serialized object.

Inject property and change values at run-time.

Until now our objects were exposing an execute method that was simply printing some fixed text in the console. But we have a name property so we should change the execute method with something like that:

  1: public void Execute() {
  2:     Console.WriteLine
  3:       ("I am a Run task. My name is: {0}",
  4:       TaskName);
  5: }
  6:

Now we have two ways to initialize the TaskName property value without using a procedural code inside the program. First of all we have to say that the TaskName property of each concrete implementation has a dependency:

  1: [Dependency()]
  2: public string TaskName {
  3:    get;set;
  4: }

And now we can change the configuration in this way:

  1: <type type="myInterface" mapTo="InversionOfControl.Model.WalkTask, InversionOfControl" name="WalkMapping" >
  2:   <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement,
  3:                      Microsoft.Practices.Unity.Configuration">
  4:     <property name="TaskName"  propertyType="System.String">
  5:       <value value="SecondTask"/>
  6:     </property>
  7:   </typeConfig>
  8: </type>
  9:

We are assigning for the mapping called WalkMapping a value of “SecondTask” for the property TaskName. This solution is fine but it’s still fixed. I mean, and if I would like to change the value at run-time and I cannot access the serialization of my object?

Here is coming the second solution:

  1: container.Configure<InjectedMembers>()
  2:    .ConfigureInjectionFor<RunTask>(
  3:    //.ConfigureInjectionFor<IBaseTask>(
  4:    //.ConfigureInjectionFor<WalkTask>(
  5:       new InjectionProperty("TaskName", "12345"));

I put a couple of comments to show you what you can configure.

I hope this short article will be useful to evaluate this amazing IoC framework.

Tags: IoC Unity Dependency Injection

WPF and MVVM tutorial 07, the List search.

Raffaeu — Fri, 03 Jul 2009 19:01:00 GMT

Ok, starting from this post we are going to do something really interesting. In this episode we need to create a simple List windows, but as you will see the logic will not be so different then a one-to-many form.

This will be the final result:

The ViewModel for the List Window.

First of all we need to create the view model. The view model should have the following commands:

New – Add a new Customer
Save – Save all the changes we did …
Edit – Edit the current selected customer
Delete – Delete the current selected customer
Text box and search button – to operate search activity
Exit the form

Then we need to add the following objects:

An observable collection for the list of customers
A current customer object, but this is not mandatory …
The search information we retrieve from the view, or better, the view sends to us.

The final result will be this view model class:

Let’s have a look at the View Model commands. As you know when we assign a RelayCommand, we can do it in 2 ways:

By passing with a lambda expression the corresponding action.

By passing with a lambda expression the corresponding action and a predicate (something like true/false).

So for some commands like Save or Delete we can also build a predicate action like CanSave? CanDelete? and encapsulating some validation logic inside.

So the code should look like:

The RelayCommands.

Simple command like Create a new customer:

  1: //Private field
  2: public ViewCommand newCommand;
  3: //Public property to be assigned in the XAML code
  4: public ViewCommand NewCommand {
  5:    get {
  6:       if (newCommand == null)
  7:          newCommand = 
  8:          //Lambda expression for assigning the action
  9:          new ViewCommand(param => this.NewCustomer());
 10:       return newCommand;
 11:    }
 12: }
 13: //Real routine executed in the ViewModel
 14: private void NewCustomer() {
 15:    NavigationActions.OpenCustomerView();
 16: }
 17:

Or something more complex like Delete a customer:

  1: //Private command field
  2: private ViewCommand deleteCommand;
  3: //Public databinded ICommand
  4: public ViewCommand DeleteCommand {
  5:    get {
  6:       if (deleteCommand == null) {
  7:       deleteCommand = new ViewCommand(
  8:           param=>this.DeleteCustomer(),
  9:           //Lambda expression for evaluating the execution
 10:           param=>this.CanDeleteCustomer
 11:           );
 12:       }   
 13:       return deleteCommand;
 14:    }
 15: }
 16: //Real delete command
 17: public void DeleteCustomer() {
 18:    if (SelectedCustomer != null) {
 19:       if(NavigationActions.QueryConfirmation(
 20:          "Delete Customer.",
 21:          string.Format("Do you want to delete {0}?",SelectedCustomer.FirstName))){
 22:          ListOfCustomers.Remove(SelectedCustomer);
 23:          repository.DeleteCustomer(SelectedCustomer);
 24:       }
 25:    } else {
 26:       NavigationActions.ShowError(
 27:         "Delete Customer.", 
 28:         "You must select a Customer!");
 29:    }
 30: }
 31: //Additional logic can go here ...
 32: private bool CanDeleteCustomer {
 33:    get { return true; }
 34: }
 35:

Then of course we will have two different command for Edit a Customer or create a new one, and at the end the difference will be just here:

  1: //Open the Customer window empty
  2: NavigationActions.OpenCustomerView();

  4: NavigationActions.OpenCustomerView(SelectedCustomer);
  3: //Open the Customer window passing a Customer
  5: 
  6:

The others commands are the same, but if you want in my solution you can find the complete implementation.

Loading and working with a Collection.

After we build all the commands and we bind them to the XAML code, we need to load our entities. For this we will use a ObservableCollection List that we will implement in the initialization of our View Model, so when the Window will open we will also load the Collection inside the ListView.

  1: //We need an instance of our repository
  2: CustomerRepository repository;
  3: //This will contain our Customers
  4: ObservableCollection<Customer> listOfCustomers;
  5: //This will be the current selected customer
  6: Customer selectedCustomer;
  7: public CustomersViewModel() {
  8:    if (repository == null) {
  9:       //Initialization of the Repository
 10:       repository = new CustomerRepository();
 11:    }
 12:    Initialization of the List
 13:    listOfCustomers = 
 14:       new ObservableCollection<Customer>(
 15:          repository.GetAllCustomers());
 16:    this.SearchText = "Some text to search ...";
 17: }
 18: //Binded property containing the Customer list
 19: public ObservableCollection<Customer> ListOfCustomers {
 20:    get { return listOfCustomers; }
 21: }
 22:

INotifyPropertyChanged

If we want to advise the UI that we loaded a new customers list, we have to build a ViewModel that implements the INotifyPropertyChanged in this way:

  1: #region INotifyPropertyChanged Members
  2: 
  3: public event PropertyChangedEventHandler PropertyChanged;
  4: 
  5: public void NotifyPropertyChanged(String info) {
  6:    if (PropertyChanged != null) {
  7:       PropertyChanged(
  8:          this, 
  9:          new PropertyChangedEventArgs(info)
 10:       );
 11:    }
 12: }
 13: 
 14: #endregion

And then change the property code in this way:

  1: public ObservableCollection<Customer> ListOfCustomers {
  2:     
  3:     get { return listOfCustomers; }
  4:     private set {
  5:         if (listOfCustomers != value) {
  6:             listOfCustomers = value;
  7:             NotifyPropertyChanged("ListOfCustomers");
  8:         }
  9:     }
 10: }

Now, everytime we are going to load something new into the collection, or we are going to use a view of the collection the ViewModel will send a message in the view saying “Hey, look I changed something in the list, update the UI!!”.

Some XAML code.

Now we have the Commands, the Model and we need to bind them to the view.

Loading the viewmodel into the view:

  1: ...
  2: <xmlns:vm=
  3:    "clr-namespace:MVVM.ViewModel;
  4:    assembly=MVVM.ViewModel />
  5: 
  6: ...
  7: <Window.DataContext>
  8:    <vm:CustomersViewModel/>
  9: </Window.DataContext>

Binding one command to a Button:

  1: <Button Name="btnNew" Command="{Binding Path = NewCommand}">

Binding the List to the ListView and assigning the selected customer:

  1: <ListView 
  2:   Name="lstCustomers" 
  3:   ItemsSource="{Binding Path=ListOfCustomers}"
  4:   SelectedItem="{Binding Path=SelectedCustomer}" 
  5:   SelectionMode="Single"
  6:   IsSynchronizedWithCurrentItem="True"
  7:   HorizontalAlignment="Stretch" 
  8:   VerticalAlignment="Stretch"
  9:   MinHeight="100">

The IsSynchronizedWithCurrentItem bind the listview and the selecteditem together.

Now, what we should be able to do here is to Load the customers, press delete and wipe one or more then one. Then:

If we close the window and we reopen it the Customer will re-appear again.
If we commit all the changes with the SaveCommand and the we close and re-open the window, the Customer will not be there anymore.

In this lesson we will see only how to implement the search function. In the next one we will see each single command in details.

The user types some text and after that he searches for a result.

  1: private void FindCustomers() {
  2:    //If there is no text, prompt an error
  3:    //In the future this will be a XAML trigger
  4:     if (this.SearchText == string.Empty || this.SearchText == null) {
  5:         NavigationActions.ShowError("Search Customers.", "Please enter some text ...");
  6:         return;
  7:     }
  8:    //Keep the search text and build a dynamic query for the DAL
  9:     ListOfCustomers = new ObservableCollection<Customer>(
 10:         repository.GetCustomersByQuery(
 11:         p => p.CompanyName.StartsWith(SearchText)
 12:         || p.FirstName.StartsWith(SearchText)
 13:         || p.LastName.StartsWith(SearchText)));
 14: }
 15:

At this point we will have a first final search solution like these screenshots:

Tags: MVVM Model View ViewModel WPF

WPF and MVVM tutorial 06, start up form.

Raffaeu — Wed, 17 Jun 2009 16:31:00 GMT

Today we are going to create the start-up form of our project and use the first ViewModel to run the application logic.

The result we want to obtain will be:

The View Model for the Startup form.

In our project, let’s go to the ViewModel section and create a new class. This class will inherit from the basic View Model class like the code below:

  1: public class StartViewModel : ViewModel {
  2: 
  3:    public StartViewModel() {
  4: 
  5:    }
  6: }

Then we need to create 2 commands that we will then associate to two buttons in our XAML form. One will start the application and one will shut-down the application.

This is the implementation we need to do in our ViewModel in order to create the Relay Command:

  1: public ViewCommand startCommand;
  2: public ViewCommand StartCommand {
  3:     get {
  4:         if (startCommand == null)
  5:             startCommand = new ViewCommand
  6:                  (param => this.StartApplication());
  7:         return startCommand;
  8:     }
  9: }
 10:

Then we need a delegate for the relay command in this way:

  1: private void StartApplication() {
  2:   NavigationActions.OpenCustomersView();
  3: }
  4:

The first XAML Form of our Application.

I am not a guru in windows design, especially the fancy UI but the final project will have a startup form like this one:

First of all add a new XAML form into the UI layer and then let’s see at the XAML code:

  1: <Window x:Class="MVVM.WPFView.Start"
  2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  4:     xmlns:vm="clr-namespace:MVVM.ViewModel;assembly=MVVM.ViewModel"
  5:         Title="MVVM AdventureWorks Application." 
  6:         Height="500" Width="500"
  7:         WindowStartupLocation="CenterScreen" WindowState="Normal"
  8:         WindowStyle="None">
  9:

If you look at the line 4, we added a reference to our viewmodel namespace. In this way we can use in a declarative way the objects in the viewmodel namespace, directly into XAML (I personally hate to use procedural code into XAML!)

  1:     <Window.DataContext>
  2:         <vm:StartViewModel />
  3:     </Window.DataContext>
  4:

Then we add as a resource, the StartViewModel view model into our Window. In this way when the window will load the XAML declaration will inform the CLR to load a default instance of our view model.

Now let’s view the two buttons:

  1: <Button Name="btnStart" Margin="5" 
  2: IsDefault="True" 
  3: Command="{Binding Path=StartCommand}">

The binding will be the Relay Command we have previously created in the View model class. Easy right?

Now, the next step will be to build the View model to show all the customers. Then we will build some specific command for the C.R.U.D. operations.

Stay tuned!

Tags: MVVM Model View ViewModel WPF

WPF and MVVM tutorial 05, The basic ViewModel.

Raffaeu — Tue, 16 Jun 2009 21:11:00 GMT

As we saw in the previous posts, a view model should be an abstract implementation of what the view needs to show about the model. We should implement an observable collection of something, we should implement an INotifyPropertyChanged interface and we should have a collection of RelayCommands.

For these reasons, it simply to understand that we need a basic abstract ViewModel class, just to recycle some code.

The Basic View Model.

  1: namespace MVVM.ViewModel {
  2:     public abstract class ViewModel:INotifyPropertyChanged,IDisposable {
  3: 
  4:         INavigationActions navigator;
  5: 
  6:         public ViewModel() {
  7:             navigator = Application.Current as INavigationActions;
  8:             if (navigator != null) {
  9:                 navigator.PropertyChanged += application_PropertyChanged;
 10:             }
 11:         }
 12: 
 13:         void application_PropertyChanged(object sender, PropertyChangedEventArgs e) {
 14:             if (string.IsNullOrEmpty(e.PropertyName) || e.PropertyName == "View")
 15:                 OnPropertyChanged("View");
 16:         }
 17: 
 18:         public INavigationActions NavigationActions {
 19:             get {
 20:                 return navigator;
 21:             }
 22:             set {
 23:                 if (navigator != value) {
 24:                     SetAction(value);
 25:                     OnPropertyChanged("NavigationActions");
 26:                 }
 27:             }
 28:         }
 29: 
 30:         protected virtual void SetAction(INavigationActions value) {
 31:             if (navigator != null)
 32:                 navigator.PropertyChanged -= application_PropertyChanged;
 33:             navigator = value;
 34:             if (navigator != null)
 35:                 navigator.PropertyChanged += application_PropertyChanged;
 36:         }
 37: 
 38:         #region INotifyPropertyChanged Members
 39:         /// <summary>
 40:         /// Raised when a property has a new value
 41:         /// </summary>
 42:         public event PropertyChangedEventHandler PropertyChanged;
 43:         /// <summary>
 44:         /// Raise the event
 45:         /// </summary>
 46:         /// <param name="propertyName">Property name that has new value</param>
 47:         protected virtual void OnPropertyChanged(string propertyName) {
 48:             PropertyChangedEventHandler handler = this.PropertyChanged;
 49:             if (handler != null) {
 50:                 var e = new PropertyChangedEventArgs(propertyName);
 51:                 handler(this, e);
 52:             }
 53:         }
 54:         #endregion
 55: 
 56:         #region IDisposable Members
 57:         /// <summary>
 58:         /// Implementation of the dispose method
 59:         /// </summary>
 60:         public void Dispose() {
 61:             this.OnDispose();
 62:         }
 63:         /// <summary>
 64:         /// The child class should implement a personal dispose procedure
 65:         /// </summary>
 66:         protected virtual void OnDispose() {
 67:             //do nothing because abstract
 68:         }
 69: 
 70:         #endregion
 71:     }
 72: }

A small summary of our code:

An implementation of the INotifyPropertyChanged that we can use in the concrete views.
An implementation of the IDisposable in order to clean our objects like collections and repositories.
An INavigator interface to implement the navigation of our application. In this case I am using the navigator pattern for composite WPF applications. Beware because this is my implementation for the navigation but it depends on how you design your app (multi-win, tab, MDI).

The INavigator implementation.

The are thousands of ways to implement a navigator engine. The only common purpose in MVVM is that the View Model doesn’t know the View but the View knows the View Model. So in our example which part of the View can interact with the application and doesn’t need to know the View Model? The app.xaml file!

My idea is this one:

We will have a simple interface in the ViewModel namespace which will identify the navigation commands we want to execute:

  1: public interface INavigationActions:INotifyPropertyChanged 
  2: {
  3:     void OpenCustomersView();
  4:     void OpenCustomerView();
  5:     void OpenOrdersView();
  6:     void OpenOrderView();
  7:     void CloseCurrentView();
  8:     void CloseApplication();
  9:     bool QueryConfirmation(string title, string message);
 10:     void ShowError(string title, string message);
 11: }

In this way we can call everything from our viewmodel that doesn’t know the view.

Now we just need to implement the view in the Application file in this way:

  1: public partial class App : Application,INavigationActions,INotifyPropertyChanged {
  2:     #region INavigationActions Members
  3: 
  4:     public void OpenCustomersView() {
  5:         CustomersView customersView = new CustomersView();
  6:         customersView.Show();
  7:     }
  8: 
  9:     public void OpenCustomerView() {
 10: 
 11:     }
 12: 
 13:     public void OpenOrdersView() {
 14: 
 15:     }
 16: 
 17:     public void OpenOrderView() {
 18: 
 19:     }
 20: 
 21:     public void CloseCurrentView() {
 22: 
 23:     }
 24: 
 25:     public void CloseApplication() {
 26:         Application.Current.Shutdown();
 27:     }
 28: 
 29:     public bool QueryConfirmation(string title, string message) {
 30:         return MessageBox.Show(title, message, MessageBoxButton.YesNo, MessageBoxImage.Question) == MessageBoxResult.Yes;
 31:     }
 32: 
 33:     public void ShowError(string title, string message) {
 34:         MessageBox.Show(title, message, MessageBoxButton.YesNo, MessageBoxImage.Error);
 35:     }

And there we go!!

Ops I forgot to mention that in the basic View Model we need to handle the INavigation

  1: public ViewModel() {
  2:     navigator = Application.Current as INavigationActions;
  3:     if (navigator != null) {
  4:         navigator.PropertyChanged 
  5:         += application_PropertyChanged;
  6:     }
  7: }
  8:

For the rest you need to wait the next tutorial!!

Tags: MVVM Model View ViewModel WPF

WPF and MVVM tutorial 04, The Commands.

Raffaeu — Mon, 15 Jun 2009 17:08:00 GMT

In the previous posts we saw the basic of our project, the model (domain entities) and a simple repository.

Note: please note that the sample I wrote about an agnostic UnitOfWork is just to show you a simple pattern to handle L2S but it can be done better.

The ViewModel.

What is the view model? Well the simplest explanation is enclosed in this definition: the view model should be the datacontext of our view. It should provide the commands, the observable collections used in the view and the error logic.

Before starting to view how to build the basic abstract class for the viewmodel I want to talk about the Relay Command and the Routed Command and their differences.

Routed or Relay command?

I have found a useful explanation here, in the Josh Smith blog. Routed events are events designed to work in a tree of elements. When a user click the text over a button, the even travels over the tree until it will find the Click event of the chrome button. This is how a button implements a routed events:

  1: public class Button:ButtonBase
  2: {
  3:    static Button()
  4:    {
  5:       Button.ClickEvent = EventManager.RegistedRoutedEvent
  6:          ("Click", RoutingStrategy.Bubble,
  7:           typeof(RoutedEventHandler), typeof(Button));
  8:    }
  9:    public RoutedEventHandler Click
 10:    {
 11:       add { AddHandler(Button.ClickEvent,value); }
 12:       remove { RemoveHandler(Button.ClickEvent,value); }
 13:    }
 14:    protected override void 
 15:       OnMouseLeftButtonDown(MouseButtonEventArgs e){
 16:       RaiseEvent(new RoutedEventArgs(Button.ClickEvent,this);
 17:    }
 18: }

The commands in WPF represent a more independent action from their user interface. Also WPF and NET expose a default set of commands that we can easily handle in our application, like:

Application command, ComponentCommand, MediaCommand, NavigationCommand and EditingCommand.

They inherit all, from the ICommand interface. So for each command you want to implement, it should inherit from ICommand in this way:

  1: #region ICommand Members
  2: 
  3: public bool CanExecute(object parameter) {
  4:     return _canExecute == null ? true : _canExecute(parameter);
  5: }
  6: 
  7: public event EventHandler CanExecuteChanged {
  8:     add { CommandManager.RequerySuggested += value; }
  9:     remove { CommandManager.RequerySuggested -= value; }
 10: }
 11: 
 12: public void Execute(object parameter) {
 13:     _execute(parameter);
 14: }
 15: 
 16: #endregion

So it becomes simple to understand that we should have a View Model abstract class that contains an abstract implementation of a collection of ICommand. Then we can inherits each view model from this one!

So our conclusion is that:

The key difference is that RoutedCommand is an ICommand implementation that uses a RoutedEvent to route through the tree until a CommandBinding for the command is found, while RelayCommand does no routing and instead directly executes some delegate. In a M-V-VM scenario a RelayCommand (DelegateCommand in Prism) is probably the better choice all around.

The final implementation of the Relay command should be something like:

In the next tutorial we will see how to build the abstract layer for a basic view model with a basic collection of relay commands.

Tags: MVVM Model View ViewModel WPF

Technorati test.

Raffaeu — Thu, 11 Jun 2009 12:22:33 GMT

kyrprtqfs9

Technorati Profile

WPF and MVVM tutorial 03, The user repository.

Raffaeu — Fri, 05 Jun 2009 19:18:00 GMT

Before starting to view in depth our model, or to design the views, I want to complete the DAL layer. Now that we have our unit of work implementation and our data context we need to implement a couple of repositories.

If you want to view how it should work a repository, I suggest this interesting article from Martin Fowler. The presenter should be:

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection.

The Flow of our application.

During the time I saw different repositories. One for each entity, one for each View and so on. My approach, usually, is to use a relationship of 1-to-1 from the view and the repository. So in our case we will have:

1 - The user opens the program and has to decide (search a customer, view all customers)

2 – A list will be presented to the user (filtered or not) and he will have to select one customer.

3 – A third view will show the details of the user, with two sub-view (address and order details).

So this is the flow that we will follow. For these reasons, you will easily understand that we need a couple of repositories: A) a user repository, B) an order repository.

The User repository.

The user repository has to give us a way to execute any kind of CRUD operation against our database. So we should have something like:

Here there are some basic operations we must be able to accomplish with our repository.

1) Get a specific Customer or Get all of them.

2) Add, Update or Drop a Customer.

3)Commit the changes to the data-model.

The code is very simple. First of all we need to create a sealed repository, so that nobody will play with it, for this purpose there is the IUnitOfWOrk interface …

  1: public sealed class CustomerRepository {
  2:     //Create an istance (it's static) of our Unit of Work
  3:     private IUnitOfWork _service;
  4:     //but let's give it a read-only access
  5:     public IUnitOfWork Service {
  6:         get { return _service; }
  7:     }
  8:     //create a new istance of the Unit of work
  9:     public CustomerRepository() {
 10:         _service = new UnitOfWork();
 11:     }
 12:

Then we need to implement the custom methods to retrieve the information we need from our model. Fortunately we have a generic unit of work so the code behind it’s very very simple!

  1: //Add a new customer
  2: public void AddCustomer(Customer _customer) {
  3:     Service.Add<Customer>(_customer);
  4: }
  5: //Drop an existing one
  6: public void DeleteCustomer(Customer _customer) {
  7:     Service.Delete<Customer>(_customer);
  8: }
  9: //Update an existing dirty customer
 10: public void UpdateCustomer(Customer _customer) {
 11:     Service.Update<Customer>(_customer);
 12: }
 13: Get a specific customer
 14: public Customer GetCustomer(int id) {
 15:     return Service.GetById<Customer>(p => p.CustomerID == id);
 16: }
 17: //Get all of them
 18: public IList<Customer> GetAllCustomers() {
 19:     return Service.GetAll<Customer>();
 20: }

We should also implement a filtered GetAllCustomers but we will use the View Model to do that in our example.

Customer class diagram.

Now we are pretty fine with our Customer model. What we have know is a model, a repository and a CRUD implementation for the customer and the related entities (Address and so on …). The final result in our DAL layer is this one:

Great we can already build now 3 views (CustomersView, CustomerView, FilteredCustomersView) just by using one repository. TO be honest we should be able to do everything but I want to keep separate the Order section.

In the next step I will give an overview of the ViewModel, and the View interaction, then we will start to build the views and then the relative ViewModels.

Ndr. I saw that this series of articles is being read by a nice number of people. Please post any ideas, suggestion or whatever you think about … I will appreciate.

Tags: MVVM Model View ViewModel WPF

WPF and MVVM tutorial 02, The model.

Raffaeu — Fri, 05 Jun 2009 13:02:00 GMT

In the first part of this tutorial we saw the MVVM model and how it works.

In this part of our tutorial we will work directly with the Entity Model and LinqToSQL. I am using a database-first approach so in my opinion using LinqToSQL will be better then Entitiy Framework. I am going also to show you an easy way to build a custom Unit Of Work to manage the context status with Linq 2 SQL.

The Visual Studio Project.

First of all open a blank Visual Studio solution, I called it WPF.Tutorial.VMMV. Add two projects on it: 1) WPF Application …UI and 2) Class Library (…DAL).

The final layout should be this one (in my picture the model is already inside).

The Data model.

If you have installed the Adventure Works database in the past you already know what I am talking about. The model I will use in the tutorial will come up with this layout:

We will have a customer with the personal information and the related orders with the order information.

Go into the DAL project and from the menu choose add new file –> LinqToSQL and call it DataModel. Now you need to connect you data model into your AW database and drag in the design pane the tables you need. At the end you should come up with the same layout I have in the previous picture.

The Unit of Work.

If you do not what I am talking about, this is the explanation by Martin Fowler.

A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you're done, it figures out everything that needs to be done to alter the database as a result of your work.

Of course with LinqToSQL we do not need a Unit of Work because L2S by itself is the data context, but because it is not able to manage the disposing in a good way, here are my 2 cents about.

We need a contract, in this way an interface in the DAL that will implement the Unit of Work:

First of all let’s build the C.R.U.D. implementation into a simple interface. In this case I am going to use the generics and the Linq expression because my project will work only with Linq so I do not need an high level of abstraction:

  1: using System;
  2: using System.Collections.Generic;
  3: 
  4: namespace WPF.Tutorials.VMMV.DAL {
  5:     public interface IUnitOfWork {
  6:         //Basic C.R.U.D. operations
  7:         void Add<T>(T _entity) where T : class;
  8:         void Delete<T>(T _entity) where T : class;
  9:         void Update<T>(T _entity) where T : class;
 10:         void Commit();
 11:         //Basic Select operations
 12:         IList<T> GetAll<T>() where T : class;
 13:         T GetById<T>(Func<T, bool> _condition) where T : class;
 14:     }
 15: }

Now we need the real Unit of Work that will inherit from our contract. We want also to inherit from IDisposable because otherwise we will not be able to keep alive our datacontext during the crud operations.

  1: using System;
  2: using System.Collections.Generic;
  3: using System.Linq;
  4: using System.Text;
  5: 
  6: namespace WPF.Tutorials.VMMV.DAL {
  7:     //Inherits IUnitOfWork and IDisposable
  8:     public class UnitOfWork:IUnitOfWork,IDisposable {
  9:         //A Static instance of the Linq Data Context
 10:         private static DataModelDataContext _service;
 11:         //The default constructor
 12:         public UnitOfWork() {
 13:             _service = new DataModelDataContext();
 14:         }

Now, the second step is to translate the UoW in something readable for Linq:

  1: //Add a new entity to the model
  2: public void Add<T>(T _entity) where T: class {
  3:     var table = _service.GetTable<T>();
  4:     table.InsertOnSubmit(_entity);
  5: }
  6: //Delete an existing entity from the model
  7: public void Delete<T>(T _entity) where T: class {
  8:     var table = _service.GetTable<T>();
  9:     table.DeleteOnSubmit(_entity);
 10: }
 11: //Update an existing entity
 12: public void Update<T>(T _entity) where T : class {
 13:     var table = _service.GetTable<T>();
 14:     table.Attach(_entity,true);
 15: }
 16: //Commit all the pending changes in the data context
 17: public void Commit() {
 18:     _service.SubmitChanges();
 19: }
 20: //Get the entire Entity table
 21: public IList<T> GetAll<T>()where T : class {
 22:     return _service.GetTable<T>().ToList();
 23: }
 24: //Get the first occurence that reflect the Linq Query
 25: public T GetById<T>(Func<T, bool> _condition) where T : class {
 26:     return _service.GetTable<T>().Where(_condition).FirstOrDefault();
 27: }
 28:

Now we have a complete Unit of Work that we will use in each repository. Ops I forgot to mention that we will not have a real repository in our solution but a view model …

Tags: MVVM Model View ViewModel WPF

WPF and MVVM tutorial 01, Introduction.

Raffaeu — Wed, 03 Jun 2009 20:41:00 GMT

With Microsoft WPF technology, a new pattern is born and is going to be called MVVM (Model View ViewModel). This pattern is an hybrid from the old MVC and the old MVP patterns. Why a new pattern for the presentation?

First of all WPF technology is giving us a kind of technology that can completely change the approach to design and code the UI. With the VMMV we can completely design an agnostic UI that doesn’t know the Model we are going to pass to it.
Recycle, I will show you in this tutorial how to simply convert a WPF application into a Silverlight app.
Better delegation and better design for a real n-tier application. In this example we will use LinqToSQL and WPF to build a complete n-tier application with the VMMV.
Something that I do not like, TESTING THE UI!! Yes we can test the UI with WPF and VMMV combination.
Abstractation. Now the view can be really abstract and you can use just a generic.xaml file and then give a style template to your model.

This is the schema (in my opinion) on how it should work an application with WPF and the VMMV implementation:

MODEL: anyone that has already worked on an n-tier application knows what it is. The model is the group of entities that will be exposed.
VIEW: the view is the graphical code XAML used to generate the UI, nothing more then that.
VIEWMODEL: the model for the view … or … the view for the model?! Anyway is a model of the view.

Before starting this tutorial I suggest you to download:

Visual Studio 2008 SP1 and NET Framework 3.5 SP1
The complete AdventureWork database template for SQL
SQL Express 2008

The next tutorial will show you how to create a simple DAL layer with LinQtoSQL and how we can implement the Unit of Work pattern to build a simple but solid data layer for our application.

You can also download the Visual Studio template here.

Tags: MVVM Model View ViewModel WPF

NET RIA Service, #Part1 install.

Raffaeu — Sun, 31 May 2009 16:02:00 GMT

In these series of posts I want to show how easy is to work with Visual Studio 2010, Silverlight 3 beta and the NET RIA Service.

Prerequisites and tutorials.

First of all we need to know what is NET RIA Service and how they can help us to write better business RIA applications.

NOTE: Unfortunately NET RIA will NOT work with the beta1 preview of Visual Studio 2010 so I recommend to use them into VS 2008 SP1.

Brad Adams and NET RIA Service overview has a very interesting post about the architecture of NET RIA Service.

Then, you must also watch the web cast at the MIX 2009. This will give a real touch of this technology that I am loving!

After all, you need now to work with the NET RIA service. I am going to write a series of posts about that, but you can also follow the tutorials over the web.

In order to develop with Silverlight 3 beta you need:

Visual Studio 2008 SP1 or Visual Studio 2010 CTP
NET RIA Services May 2009 preview
Silverlight 3 runtime and toolkit
Follow one of the numerous tutorial available

If you plan to work with Windows 7 and Visual Studio 2010, you can have a look also at my post on How to RDP into a Windows 7 virtual machine.

After that you will be able to follow my tutorials.