NHibernate blog : WPF

NHibernate and WPF: Asynchronous calls

Jose Romaniello — Mon, 23 Nov 2009 01:48:18 GMT

I will show in this article an approach to make an asynchronous call to the model, to prevent the user interface to freeze. If you read about WPF, you will see there is a lot of information and claims “don’t freeze the ui thread”, “build UI more responsiveness” and so on.

What you should know

NHibernate Sessions are not thread safe, so don’t use a single session in multiples threads. Conversation-per-Business-Transaction use the same session for a conversation. The end of the conversation flush the changes and close the session, the abort of the conversation discard changes and close the session.

You can’t update UI controls from a non-ui thread. Some people read this like “don’t set a ViewModel property from a non UI thread”. But this is not true, because it depends where do you raise the property changed notification thank to my friend German Schuager for reminding me this post from Rob Eisenberg. However, I’m not using this trick for now.

Asynchronous code is HARD to unit test. I will like to separate the asynchronous code in few units more testable and test “in-sync”.

The problem

The load of the artist list is very slow and this causes the user interface to freeze. This is very irritating for the end user.

I will break the async problem in the following three steps:

Preview: Before start the operation we want to let the user know that the operation is in-process with some message in the user interface or maybe an hourglass.
Process: The heavy operation.
Completed: The operation has ended and we want to show the result to the UI.

Show me the code

This my generic implementation of ICommand for make async calls.

public class AsyncCommandWithResult<TParameter, TResult>
        : IAsyncCommandWithResult<TParameter, TResult>
{
    private readonly Func<TParameter, bool> _canAction;
    private readonly Func<TParameter, TResult> _action;

    public AsyncCommandWithResult(Func<TParameter, TResult> action)
    {
        _action = action;
    }

    public AsyncCommandWithResult(
            Func<TParameter, TResult> action,
            Func<TParameter, bool> canAction)
    {
        _action = action;
        _canAction = canAction;
    }


    public Action<TParameter, TResult> Completed { get; set; }
    public Action<TParameter> Preview { get; set; }
    public bool BlockInteraction { get; set; }

    public void Execute(object parameter)
    {
        //Execute Preview
        Preview((TParameter)parameter);

        //This is the async actions to take... 
        worker.DoWork += (sender, args) =>
        {
            args.Result = _action((TParameter)parameter);

        };

        //When the work is complete, execute the postaction.
        worker.RunWorkerCompleted += (sender, args) =>
        {
            Completed((TParameter)parameter, (TResult)args.Result);
            CommandManager.InvalidateRequerySuggested();
        };

        //Run the async work.
        worker.RunWorkerAsync();
    }

    [DebuggerStepThrough]
    public bool CanExecute(object parameter)
    {
        if (BlockInteraction && worker.IsBusy)
            return false;

        return _canAction == null ? true :
                _canAction((TParameter)parameter);
    }

    public event EventHandler CanExecuteChanged
    {
        add { CommandManager.RequerySuggested += value; }
        remove { CommandManager.RequerySuggested -= value; }
    }

    public TResult ExecuteSync(TParameter obj)
    {
        return _action(obj);
    }

    private static readonly BackgroundWorker worker
            = new BackgroundWorker();
}

Testing the ViewModel

Here you can see the test of the three steps. None of these test involves asynchronous calls.

[Test]
public void preview_of_load_list_should_show_status_info()
{
    var browseArtistVm = new BrowseArtistViewModel(
                new Mock<IBrowseArtistModel>().Object,
                new Mock<IViewFactory>().Object);
    
    browseArtistVm.LoadListCommand.Preview(null);
    browseArtistVm.Status.Should().Be.EqualTo("Loading artists...");
}

[Test(Description = "Check if the process call the model")]
public void load_list_command_should_load_artists_coll()
{
    var artistModel = new Mock<IBrowseArtistModel>();

    var artists = new List<Artist> {new Artist {Name = "Jose"}};

    artistModel.Setup(am => am.GetAllArtists()).Returns(artists);

    var browseArtistVm = new BrowseArtistViewModel(
                            artistModel.Object, 
                            new Mock<IViewFactory>().Object);

    browseArtistVm.LoadListCommand.ExecuteSync(null);

    artistModel.VerifyAll();
}

[Test]
public void completed_of_load_l_should_load_the_list_and_change_status()
{
    var browseArtistVm = new BrowseArtistViewModel(
                new Mock<IBrowseArtistModel>().Object,
                new Mock<IViewFactory>().Object);

    var artists = new List<Artist>();

    browseArtistVm.LoadListCommand.Completed(null, artists);

    browseArtistVm.Artists.Should().Be.SameInstanceAs(artists);
    browseArtistVm.Status.Should().Be.EqualTo("Finished");
}

Implementing the ViewModel

The LoadListCommand of the ViewModel is:

public virtual IAsyncCommandWithResult<object, IList<Artist>> LoadListCommand
{
    get
    {
        if (_loadListCommand == null)
        {
            _loadListCommand = 
                new AsyncCommandWithResult<object, IList<Artist>>
                        (o => _browseArtistModel.GetAllArtists())
                        {
                            BlockInteraction = true,
                            Preview = o => Status = "Loading artists...",
                            Completed = (o, artists) =>
                                {
                                    Artists = artists;
                                    Status = "Finished";
                                }
                        };
        }
        return _loadListCommand;
    }
}

Final conclusion

You must to remember that an NHibernate Session should be used in only one thread. This model for Browsing Artists has only one method with EndMode = End. This means session-per-call, so each time I click the LoadCommand the model start a new conversation and session. If you have a ViewModel with multiples operations within the same Conversation better you use something else, or use AsyncCommand everywhere within the VM.

There are a lot of alternatives to this approach, here are some;

Event-based asynchronous pattern.
Use background thread directly in your ViewModel.

Use this only when you need it. You don’t have to do this everywhere. Some operations are very fast and inexpensive.

Divide and conquer; I really like this way of testing. Don’t bring asynchronous things to your unit tests.

NHibernate and WPF: Test Databinding with Caliburn

Jose Romaniello — Sun, 15 Nov 2009 16:42:25 GMT

As I said before, for the Chinook Media Manager I’m not using neither Caliburn nor Prism.
But, whenever I found a limitation on the current tools, I start looking a solution elsewhere. This is how I meet Caliburn.Testability, a great tool.

The problem

We don’t know what would be the ViewModel for the View at design time. This is the reason why we don’t have intelliscence in XAML, and in general our databinding are not strongly typed in XAML. So, we can write “naem” instead of “Name”.

The solution

Caliburn has a great tool named “Caliburn Testability”, you can read the full post here. As Rob Eisenberg said, I take this one step farther to build an automatic test.

This is the code:

public class DataBindingValidator
{
    private static BindingValidator ValidatorFor(
            Type guiElement, Type presenterType)
    {
        var boundType = new BoundType(presenterType);
        var instance = (DependencyObject)Activator.CreateInstance(guiElement);
        IElement element = Bound.DependencyObject(instance, boundType);
        return new BindingValidator(element);
    }

    /// <summary>
    /// Validate the bindings of a keyvalue pair 
    /// where the key is the View type and the 
    /// value is the ViewModel type.
    /// </summary>
    public IEnumerable<ValidationResult>
            Validate(IDictionary<Type, Type> viewViewModelDictionary)
    {
        foreach (var viewViewModel in viewViewModelDictionary)
        {
            BindingValidator validator
                = ValidatorFor(viewViewModel.Key, viewViewModel.Value);
            ValidationResult validatorResult = validator.Validate();
            yield return validatorResult;
        }
    }
}

This class validate a IDictionary<Type, Type>, the key is the “View” type, and the value is the ViewModel type. The View need to have a public constructor without args, this test will create an instance of the View. The ViewModel type could be a class, could be abstract and even an interface!

The test is really easy, if you are using Caliburn, you already have a IViewStrategy. The Chinook Media Manager use a convention based approach and I don’t have an special artifact for this purpose. So my test looks as follows:

[TestFixture]
public class TestDataBindings
{
    private static Type GetViewForViewModel(Type viewModelType)
    {
        string viewName = viewModelType.Name.Replace("ViewModel", "View");
        string viewFullName = string.Format("ChinookMediaManager.GUI.Views.{0}, ChinookMediaManager.GUI", viewName);
        Type viewType = Type.GetType(viewFullName, true);
        return viewType;
    }

    [Test]
    public void AllDatabindingsAreOkay()
    {
        bool fail = false;
        var databindingValidator = new DataBindingValidator();

        Type examplePresenterType = typeof(AlbumManagerViewModel);

        var dictionary = examplePresenterType.Assembly.GetTypes()
                                            .Where(type => type.Namespace.EndsWith("ViewModels"))
                                            .ToDictionary(vmType => GetViewForViewModel(vmType), vmType => vmType);

        

        foreach (var validationResult in databindingValidator.Validate(dictionary))
        {
            if(validationResult.HasErrors)
            {
                Console.WriteLine(validationResult.ErrorSummary);
                fail = true;
            }
        }

        fail.Should().Be.False();
    }
}

If you have any error in your databinding this test will fail. This test also show you a list of the DataBinding errors in the console, and for each error the full path inside the View:

You can see here the “nesting level”, Album is a property of the EditAlbumViewModel, Title is a property in the Album type. Titlo doesn’t exist. EditAlbumView.Grid.TextBox is the full xaml path to the control holding the databinding. It show Grid and TextBox because these elements doesn’t have a name in xaml.

This is why I use Caliburn.Testability in Chinook Media Manager.

NHibernate and WPF: The GuyWire

Jose Romaniello — Sat, 07 Nov 2009 19:12:52 GMT

Note: I owe this knowledge to my friend Fabio Maulo, so I would like to thank him for teaching me and letting me share.

Introduction

I will show you in this post a nice way to configure your IoC container and some other aspects of your applications. I assume for this article that you have good knowledge of dependency injection and inversion of control.

The problem

There was a time when we used to configure our containers with xml, and all was fine. Then we started to use fluent and strongly typed interfaces and a problem became more frequent and acute. Basically, when we use a fluent interface, we do something like this:

container.Register(Component.For<IAlbumRepository>()
                       .ImplementedBy<AlbumRepository>()
                       .LifeStyle.Transient);

IAlbumRepository is in Chinook.Data and AlbumRepository is in Chinook.Data.Impl.
The problem is not *how* but *where*. Where do you do this?

Most people will say “The startup project”. One of the goal that we look when using IoC is:

..decoupling of the execution of a certain task from implementation.

Pay attention to the “Decoupling” part. If you want “decoupling”: Why do you add all those references in your startup project?

This is a NDepend extracted graph of the Northwind example that comes with Sharp Architecture:

If you look at the Northwind.Web assembly you will see that it has a reference even to NHibernate. It has a reference to Northwind.Data (repositories that use NHibernate). The contract interface of repositories is in Northwind.Core. Also you can see that the start up project need a reference to Castle Container. If I want a loosely coupled solution, I don’t want some of those references.

Pay atention; the northwind example of Sharp Architecture is a very good example, is a good architecture, and this is neither a complain nor a criticism. I’m pretty sure that it defines interfaces and implementations separately, as I’m pretty sure that controllers depends upon IRepositories. But, I think it has a problem at reference level. The main problem is because the initialization of the container is in a wrong place. You could see the initialization script here.

So, what I’m looking for is:

I don’t want references to concrete implementations in my startup project.
I don’t want to depend upon a specific IoC container technology.
And finally I don’t want to configure my container in the startup project, its is another “aspect” of my application like the repositories!

The Solution

The solution is very simple. Take the container initialization to another place.

We used to call this place “The GuyWire”, in italian “Cavo Portante”, in spanish “Cable Maestro”:

A guy-wire or guy-rope is a tensioned cable designed to add stability to structures

Two simple rules to remember:

In order to configure service and implementers fluently, the GuyWire will reference everything.
Because the guy-wire reference everything, the GuyWire can not be referenced.

The guywire is an excellent place to “configure” the whole application. I used to separate the configuration in different aspects. Here some examples:

ORM configuration
Constraint Validator configuration
Repositories configuration
Entities configuration
ViewModel configuration
Controllers configuration
Views configuration

You can explore the configurators of ChinookMediaManager here.

How does it works?

The guywire project has an special “Output Path”:

So, the path is the “Startup” project.

Secondly, in the App.Config, I have a config like this:

<appSettings>
  <add key="GuyWire" value="ChinookMediaManager.GuyWire.GeneralGuyWire, ChinookMediaManager.GuyWire" />
</appSettings>

And finally, in my App.Xaml.cs:

public partial class App : Application
{
    private readonly IGuyWire guyWire = ApplicationConfiguration.GetGuyWire();

    public App()
    {
        guyWire.Wire();
    }

    protected override void OnStartup(StartupEventArgs e)
    {
        var viewFactory = ServiceLocator.Current.GetInstance<IViewFactory>();
        viewFactory.ShowView<BrowseArtistViewModel>();
    }

    protected override void OnExit(ExitEventArgs e)
    {
        guyWire.Dewire();
        base.OnExit(e);
    }
}

The interface IGuyWire and other classes needed for doing this, are in unhaddins.

The reference graph of the Chinook Media Manager, is as follows:

A last word about the Configurators

I really like the idea of have different parts of the application configuration in separated classes. I used to reuse this configurators alone in my Tests. But, as a I said before, the guywire should not be referenced by any project. So, my trick is add the configurator as a “linked file” to the test project:

And this is a sample:

[TestFixture]
public class AlbumValidationFixture
{
    private IWindsorContainer container;

    [TestFixtureSetUp]
    public void FixtureSetUp()
    {
        container = new WindsorContainer();
        var configurator = new NHVConfigurator();
        configurator.Configure(container);
    }

    [Test]
    public void title_constraints()
    {
        GetConstraint<Album, NotEmptyAttribute>(a => a.Title)
            .Message
            .Should().Be.EqualTo("Title should not be null.");

        GetConstraint<Album, LengthAttribute>(a => a.Title)
            .Should().Be.OfType<LengthAttribute>()
            .And.ValueOf.Message.Should().Be.EqualTo("Title should not exceed 200 chars.");
            
        
    }
}

I will not talk about this long break in the series. If you are interested in Wpf and Nhibernate, you should be happy because; I'M BACK!

Nhibernate and WPF: Validations

Jose Romaniello — Fri, 28 Aug 2009 01:06:36 GMT

Part I: Introducing NHiberate and WPF: The ChinookMediaManager
Part II: Nhibernate and WPF: The core
Part III: Nhibernate and WPF: Models concept
Part IV :Nhibernate and WPF: ViewModels and Views

In this post I will show you an easy way to handle validations in WPF.

In System.ComponentModel we have an interesting interface named IDataErrorInfo.
This interface has two members:

IDataErrorInfo.Item: Gets the error message for the property with the given name.
IDataErrorInfo.Error: Gets an error message indicating what is wrong with this object.

The interesting side of this interface is that if we implement this in our domain classes, the presentation layer will automatically resolved certain things.

Side note: This interface was made with DataTables in mind.

Validation Framework

I really like NHibernateValidator, in the same way that I like NHibernate. But, in uNhAddIns we have a main principle: “those two are just options”, so you can change whenever you want to use anything else (Validation Application Block, Validation Framework, Castle Validators, xVal).

For that matter, Fabio Maulo developed a simple interface named IEntityValidator, this is part now of the uNhAddIns.Adapters project. If you want to use Nhibernate Validator the EntityValidator is already implemented here. If you want to use another validator framework please implement the interface and send us the patch ;-).

How To

Implementing IDataErrorInfo directly in domain classes is a waste of time and also is too much invasive, because will end with a dependency in the IEntityValidator. Since we already know how to build injectable behavior we can address this problem in the same way.

I build a new DynamicProxy IInterceptor you could see the implementation here.

The configuration of the Album entity, now looks as follows:

container.Register(Component.For<Album>()
                                    .NhibernateEntity()
                                    .AddDataErrorInfoBehavior()
                                    .AddNotificableBehavior()
                                    .LifeStyle.Transient);

The configuration of Nhibernate.Validator is very easy and I don’t want to repeat myself.
Then you need to register an IEntityValidator as follows:

container.Register(Component.For<IEntityValidator>()
                            .ImplementedBy<EntityValidator>());

You have three way to write validations with NHibernate Validator: Xml, Fluent and Attributes. This is aleady very well explained in this post.

In the VIEW the only thing that we need to enable is the ValidateOnDataErrors attribute, this is an example textbox:

<TextBox Text="{Binding Path=Album.Title, ValidatesOnDataErrors=true}" />

I’ve a shared a resource for views, as follows:

<Style TargetType="{x:Type TextBox}">
    <Style.Triggers>
        <Trigger Property="Validation.HasError" Value="true">
            <Setter Property="ToolTip"
            Value="{Binding RelativeSource={RelativeSource Self}, 
                   Path=(Validation.Errors)[0].ErrorContent}"/>
        </Trigger>
    </Style.Triggers>
</Style>

This means: “textbox should display validation errors in tooltip”.

This is all. What?, you don’t believe me.

See the behavior in action

See the screencast here.

Oh, and I almost forgot, this behavior should also work in ASP.NET Mvc.

Nhibernate and WPF: ViewModels and Views

Jose Romaniello — Wed, 19 Aug 2009 16:23:46 GMT

Part I: Introducing NHiberate and WPF: The ChinookMediaManager
Part II: Nhibernate and WPF: The core
Part III: Nhibernate and WPF: Models concept

In this post I will introduce some concepts about the presentation layer of the Chinook Media Manager example.

Prerequisites

If you are new to the MVVM pattern I will strongly recommend you these blogs post:

Introduction

I will quote John Smith:

The single most important aspect of WPF that makes MVVM a great pattern to use is the data binding infrastructure. By binding properties of a view to a ViewModel, you get loose coupling between the two and entirely remove the need for writing code in a ViewModel that directly updates a view.

This is the more important thing that you need to remember. Unlike the MVP pattern the viewmodel never updates the UI, the ui is automatically updated by the databinding infrastructure. Also you has to keep in mind that all in the MVVM is about databinding, even events.

I chose to separate Views and ViewModels in differents assembly, although I saw these two together in a bunch of samples. For the other hand the interfaces of the ViewModels are defined in the Views assembly.

The “Album Manager” use case

If we recall my first post the UI was this:

I will separate this use case in two views and viewmodels:

The main View is called AlbumManagerView and the view inside the red border is called “EditAlbumView”. The reason for why I’m doing this is clear: “I need somehow to separate the problem into smaller parts”. And as I say in the “Models concept” post a use-case can expand multiples views.

To complicate things a bit, the user told us that would like to be able to simultaneously edit multiple albums. So, I will use the workspace sample of John Smith.

The AlbumManager

When I start to define a View, the first thing is the ViewModel interface, in this case:

public interface IAlbumManagerViewModel : INotifyPropertyChanged
{
    /// <summary>
    /// Setup the view, load the albums collection.
    /// </summary>
    /// <param name="artist"></param>
    void SetUp(Artist artist);

    /// <summary>
    /// Expose a bindable collection of albums.
    /// </summary>
    IEnumerable<Album> Albums { get; }

    /// <summary>
    /// Get or Set the selected album.
    /// </summary>
    Album SelectedAlbum { get; set; }

    /// <summary>
    /// Open an edition workspace for editing the selected album.
    /// </summary>
    ICommand EditSelectedAlbumCommand { get; }

    /// <summary>
    /// Commit all the changes.
    /// </summary>
    ICommand SaveAllCommand { get; }

    /// <summary>
    /// Discard all the changes.
    /// </summary>
    ICommand CancelAllCommand { get; }

    /// <summary>
    /// WorkSpace open.
    /// </summary>
    ObservableCollection<IEditAlbumViewModel> AlbumEditWorkspaces { get; }
}

In the introduction I said that MVVM use databinding even for events .
So, what is an ICommand? ICommand interface has three members: CanExecuteChanged, CanExecute and Execute. The object that is bound to this command (aka command source), disable itself if the command cann’t be executed. You can bind KeyGestures, MouseActions, buttons and so on. More on this topic here.

The second step is to start writing a test for the concrete implementation of the viewmodel.

[TestFixture]
public class AlbumManagerViewModelTest
{
    [Test]
    public void setup_viewmodel_should_work()
    {
        var albumManagerModel = new Mock<IAlbumManagerModel>();

        var artist = new Artist { Name = "John" };
        var albumList = new List<Album> { new Album() { Artist = artist } };

        albumManagerModel.Setup(am => am.GetAlbumsByArtist(artist))
                         .Returns(albumList)
                         .AtMostOnce();


        var albumManagerVm = new AlbumManagerViewModel(albumManagerModel.Object, 
                                                       viewInsantiator.Object);

        var eventWasRaised = false;

        albumManagerVm.PropertyChanged +=
            (sender, args) =>
            {
                //property changed should be raised AFTER the property change.
                if ("Albums".Equals(args.PropertyName))
                {
                    albumManagerVm.Albums.Should().Be.SameInstanceAs(albumList);
                    eventWasRaised = true;    
                }
            };

        albumManagerVm.SetUp(artist);
        eventWasRaised.Should().Be.True();
        albumManagerModel.VerifyAll();

    }

When I setup an “AlbumManagerViewModel”, it should call GetAlbumByArtist of my model, and put the result in the “Albums” property. Also the viewmodel should raise the PropertyChanged for the album property, AFTER the change in the property.

The implementation is very simple:

public void SetUp(Artist artist)
{
    Albums = _albumManagerModel.GetAlbumsByArtist(artist);
}

private IEnumerable<Album> _albums;
public IEnumerable<Album> Albums
{
    get { return _albums; }
    private set
    {
        _albums = value;
        OnPropertyChanged("Albums");
    }
}

To not getting bored with the code, the full implementation of the EditSelectedAlbumCommand is here.

I will highlight interesting parts of this code:

public ICommand EditSelectedAlbumCommand
{
    get
    {
        if (_editSelectedAlbumCommand == null)
            _editSelectedAlbumCommand = new RelayCommand(
                o => EditSelectedAlbum(),
                o => SelectedAlbum != null &&!AlbumEditWorkspaces.Any(ae => ae.Album == SelectedAlbum));
        return _editSelectedAlbumCommand;
    }
}

This is the EditSelectedAlbumCommand. In the instantiation of the command you see two lambdas. The first function is the code that should be called when the commandsource call Execute. The second is the CanExecute function, as you can see it returns false when:

There isn’t a selected album.
There is another workspace editing the album.

You can find the RelayCommand in the source.

The EditSelectedAlbum method looks as follows:

private void EditSelectedAlbum()
{
    //Resolve a new instance of EditAlbumViewModel
    var newWp = _viewFactory.ResolveViewModel<IEditAlbumViewModel>();
    //Setup the new viewmodel.
    newWp.SetUp(SelectedAlbum, _albumManagerModel);
    //subscribe to close request.
    newWp.RequestClose += EditAlbumRequestClose;
    //add the new viewmodel to the workspace collection.
    AlbumEditWorkspaces.Add(newWp);
    //set the new viewmodel as the active wp.
    SetActiveWorkspace(newWp);
}

Now, the view for this viewmodel is very easy:

<StackPanel>
    <StackPanel Orientation="Horizontal" DockPanel.Dock="Top" >
        <Button Command="{Binding EditSelectedAlbumCommand}" >Edit</Button>
        <Button>Close</Button>
    </StackPanel>
    <ListBox Name="AlbumsList" 
         ItemsSource="{Binding Albums}" 
         DisplayMemberPath="Title"
         SelectedItem="{Binding SelectedAlbum}"
         DockPanel.Dock="Top" Height="302">
    </ListBox>
    <Button Command="{Binding SaveAllCommand}" >Save All</Button>
    <Button Command="{Binding CancelAllCommand}" >Cancel All</Button>
</StackPanel>

The “tabs” container is described in this peace of code:

<Border Style="{StaticResource MainBorderStyle}">
    <HeaderedContentControl 
      Content="{Binding Path=AlbumEditWorkspaces}"
      ContentTemplate="{StaticResource WorkspacesTemplate}"
      Header="Workspaces"
      Style="{StaticResource MainHCCStyle}"
      />
</Border>

The EditAlbum

I define the interface for the IEditAlbumViewModel as follows:

public interface IEditAlbumViewModel : INotifyPropertyChanged
{
    void SetUp(Album album, IAlbumManagerModel albumManagerModel);

    /// <summary>
    /// The album being edited.
    /// </summary>
    Album Album { get; }
   
    /// <summary>
    /// The title of the tab.
    /// </summary>
    string DisplayName { get; }

    /// <summary>
    /// The command to close the tab.
    /// </summary>
    ICommand CloseCommand { get; }

    /// <summary>
    /// The command to save the album.
    /// </summary>
    ICommand SaveCommand { get; }

    /// <summary>
    /// The command to add a new track to the album.
    /// </summary>
    ICommand AddNewTrackCommand { get; }

    /// <summary>
    /// The command to delete the selected track.
    /// </summary>
    ICommand DeleteSelectedTrackCommand { get; }

    Track SelectedTrack { get; set; }

    event EventHandler RequestClose;
}

The implementation is very straightforward, you can see here. One thing to mention is that I configure nhibernate to resolve all my collections with INotifyCollectionChanged, so I can add a new Track in my viewmodel and the datagrid bound to the tracks collection will be notified about that change.

What’s next?

We have several troubles with this application:

Error handling. Is simple, this is what the user see. We MUST handle unexpected exceptions, just think what would happen if we shutdown the database server.
Asynchronous calls. For now we are freezing the UI thread with database and business layer operations. We need to build responsive UI’s
Validation. I will add support to the NHibernate Validator.
Conflict resolution for concurrency problems.

Do you want to see the app working?

Here you can see the full concept of "Conversation per Business Transaction" of Fabio Maulo working.

The full source code project is here.

Special thanks to all the people mentioned in this post.

Nhibernate and WPF: Models concept

Jose Romaniello — Sun, 16 Aug 2009 00:33:46 GMT

Part I: Introducing Nhibernate and WPF
Part II: Chinook Media Manager: The Core

Introduction

For this post I will use the concept of Fabio Maulo called “Conversation-per-BussinesTransaction”. If you have not read, what are you waiting for?

Definition

This definition is extracted from Fabio’s post and is very important that you understood it:

When you read something about NHibernate-session-management is because we want abstract/”aspect” NH-session’s stuff from the code are using it. In general, or I hope so, you are using the session in something like a DAO/Repository and, in a use-case, you are calling more than one DAO/Repository. Open a new session in each DAO/Repository is an anti-pattern called session-per-call (or very closer to it). What we are searching is something to manage the session in an high-layer but without wire that layer with NHibernate. In a WEB environment it is pretty easy because we can manage the session using an implementation of a IHttpModule, or in the HttpApplication, “intercepting” the request (two patterns mentioned here). In a winForm, or WPF, aplication it is not so clear where the abstraction have place. In this post I will use an “artifact” named Model to represent the “abstraction-point” (in my mind the Model is the business-object that are using DAOs/Repository and domain-entities); in an MVC based application, probably, the abstraction have place in the Controller.

Implementation

We start defining an interface for our Use-case Model class as follows:

public interface IAlbumManagerModel
    {

        /// <summary>
        /// Search all albums from a given artist.
        /// </summary>
        /// <param name="artist"></param>
        /// <returns></returns>
        IEnumerable<Album> GetAlbumsByArtist(Artist artist);

        /// <summary>
        /// Persist an album.
        /// </summary>
        /// <param name="album"></param>
        void SaveAlbum(Album album);

        /// <summary>
        /// Revert changes of a given album to his current persisted state.
        /// </summary>
        /// <param name="album"></param>
        void CancelAlbum(Album album);

        /// <summary>
        /// Flush all changes to the database.
        /// </summary>
        void SaveAll();

        /// <summary>
        /// Cancel all changes.
        /// </summary>
        void CancelAll();
    }

As I say in my previous post this interface is defined in the “ChinookMediaManager.Domain”.
The concrete implementation is defined in ChinookMediaManager.DomainImpl as follows:

[PersistenceConversational(MethodsIncludeMode = MethodsIncludeMode.Implicit)]
    public class AlbumManagerModel : IAlbumManagerModel
    {

        private readonly IAlbumRepository albumRepository;

        public AlbumManagerModel(IAlbumRepository albumRepository)
        {
            this.albumRepository = albumRepository;
        }

        /// <summary>
        /// Search all the albums from a given artist.
        /// </summary>
        /// <param name="artist"></param>
        /// <returns></returns>
        public IEnumerable<Album> GetAlbumsByArtist(Artist artist)
        {
            return albumRepository.GetByArtist(artist);
        }

        /// <summary>
        /// Persist an album.
        /// </summary>
        /// <param name="album"></param>
        public void SaveAlbum(Album album)
        {
            albumRepository.MakePersistent(album);
        }

        /// <summary>
        /// Revert changes of a given album to his original state.
        /// </summary>
        /// <param name="album"></param>
        public void CancelAlbum(Album album)
        {
            albumRepository.Refresh(album);
        }

        /// <summary>
        /// Flush all changes to the database.
        /// </summary>
        [PersistenceConversation(ConversationEndMode = EndMode.End)]
        public void SaveAll()
        { }

        /// <summary>
        /// Cancel all changes.
        /// </summary>
        [PersistenceConversation(ConversationEndMode = EndMode.Abort)]
        public void CancelAll()
        {
        }
    }

Well, this is the non-invasive AOP way of doing with CpBT from unhaddins.
The PersistenceCovnersational attribute tell us two things:
- All methods are involved in the conversation if not explicitly excluded.
– All methods ends with “Continue” if not explicitly changed.
SaveAll end the conversation with EndMode.End, this means that the UoW will be flushed.
For the other hand CancelAll end with Abort, this means that all changes are evicted and the conversation is not flushed.

Testing the model

Testing is very simple, all you need to do is to mock your repositories as follows:

[Test]
public void can_cancel_album()
{
    var repository = new Mock<IAlbumRepository>();
    var album = new Album();
    repository.Setup(rep => rep.Refresh(It.IsAny<Album>()))
              .AtMostOnce();

    var albumManagerModel = new AlbumManagerModel(repository.Object);

    albumManagerModel.CancelAlbum(album);

    repository.Verify(rep => rep.Refresh(album));
}

In this test I’m using the Moq library.
The other thing that we need to test is the conversation configuration, my first approach was to test the attributes, but owned by the fact that we can configure the CpBT in many ways (such as XML), this is my test:

[TestFixtureSetUp]
public void FixtureSetUp()
{
    conversationalMetaInfoStore.Add(typeof (AlbumManagerModel));
    metaInfo = conversationalMetaInfoStore.GetMetadataFor(typeof(AlbumManagerModel));
}

[Test]
public void model_represents_conversation()
{
    metaInfo.Should().Not.Be.Null();
    metaInfo.Setting.DefaultEndMode.Should().Be.EqualTo(EndMode.Continue);
    metaInfo.Setting.MethodsIncludeMode.Should().Be.EqualTo(MethodsIncludeMode.Implicit);
}

[Test]
public void cancel_all_abort_the_conversation()
{
    var method = Strong.Instance<AlbumManagerModel>
        .Method(am => am.CancelAll());

    var conversationInfo = metaInfo.GetConversationInfoFor(method);

    conversationInfo.ConversationEndMode
                    .Should().Be.EqualTo(EndMode.Abort);
}

[Test]
public void save_all_end_the_conversation()
{
    var method = Strong.Instance<AlbumManagerModel>
        .Method(am => am.SaveAll());

    var conversationInfo = metaInfo.GetConversationInfoFor(method);

    conversationInfo.ConversationEndMode
                    .Should().Be.EqualTo(EndMode.End);
}

I'm using a strongly typed way to get the MethodInfo extracted from this example.

Nhibernate and WPF: The core

Jose Romaniello — Sun, 16 Aug 2009 00:30:52 GMT

Part I: Introducing NHiberate and WPF: The ChinookMediaManager

Introduction

This is my second post about the Chinook Media Manager, an example application for NHibernate and WPF. In this post I will outline some concepts behind the architecture that I’ve chosen.

Note

Probably at some points you will feel that this is over-architected, YAGNI and so on. Yes, you are right I’m not trying to bind a grid to a collection of objects there are tons of samples on the net about that subject.

The four musketeers

The core of the application is composed of four components:

ChinookMediaManager.Data: Contains the definition of repositories interfaces.
ChinookMediaManager.DataImpl: Contains the implementation of these repositories plus other nhibernate things that we will need to make work the implementation of repositories (like mappings).
ChinookMediaManager.Domain: Contains the domain classes plus model interfaces (we will focus on this concept latter)
ChinookMediaManager.DomainImpl: Contains the implementation of the models.

My base repository definition is as follows:

public interface IRepository<T> : IQueryable<T>
    {
        T Get(object id);
        T Load(object id);
        T MakePersistent(T entity);
        void Refresh(T entity);
        void MakeTransient(T entity);
    }

This means that a repository is a IQueryable<T> by itself and we can build queries in a more natural way.
I have seen a lot of repositories implementations with methods Save, Update and Delete, there is nothing wrong with it, just that I think that MakePersistent (Save) and MakeTransient (Delete) better represents that functionality (I have stolen this terminology from a Gustavo Ringel’s example).
You could find the implementation here.

Don’t touch “the domain”

Working with WPF sometimes you will need that your entities implement INotifyPropertyChanged or IEditableObject for data binding. Although the implementation of those interfaces is simple, if you implement directly in your domain you will tie your domain to a presentation concern and also will end writing a lot of code.

So, I wrote an addin for nhibernate (unhaddins.wpf) that will help you to inject those behaviors without touching anything in your domain model.

We only have to add the entity to the container as follows:

container.Register(Component.For<Album>()
    .NhibernateEntity()
    .AddNotificableBehavior()
    .LifeStyle.Transient);

If you need to add editable object behavior (read this and this) you simple put “.AddEditableBehavior()”.
If we want a transient instance we will request it to the container (or an object factory). In unhaddins we have got an artifact that allows nhibernate to instantiate entities from the container, read this post from Fabio Maulo.

For INotifyCollectionChanged, unhaddins.wpf has a Collection Type Factory, we need to configure NHibernate as follows:

nhConfiguration.Properties[Environment.CollectionTypeFactoryClass] =
  typeof (WpfCollectionTypeFactory).AssemblyQualifiedName;

With this simple step all bag, sets and list (more coming up) of objects retrieved from NHibernate will implement INotifyCollectionChanged.

It goes without saying that this configuration is not in the domain.

As you can see, I don’t have to put presentations concerns inside “the four musketeers”.

In the next post I will talk about models and CpBT.

Introducing NHiberate and WPF: The ChinookMediaManager

Jose Romaniello — Sun, 16 Aug 2009 00:26:25 GMT

As you can note in my previous posts I’ve talked a lot about NHibernate and WPF. So I've decided to write an ongoing series of blog posts about the integration of these two technologies.

Motivation

The motivation behind this series of posts is very simple most of the articles that you can read about NHibernate are for web technologies such as ASP.Net or ASP.NET MVC. Despite the fact that NHibernate is an ORM and has nothing to do with the presentation layer there are certain consideration that you have to take into account to build a good architecture.

Sample Domain

For this series of post I have chosen to use a small subset of the Chinook database with few modifications. I have changed all the Identities primary keys to HiLo. You can find both the original and the slightly modified version here (with class, mappings and read only tests).

This is the full database schema:

However we will focus in this subset of the domain:

A word about session management

Most of the examples of NHibernate for web applications uses a pattern called “Session-per-Request”, this means that the session and the transaction has the same lifetime that the web request. This pattern is very easy to work with and very easy to understood but is not suitable for desktop applications.
There are two antipatterns called “session-per-application” and “session-per-call” that you need to avoid.
The pattern that I will use for this series is called “conversation per bussines transactions” and is very well described by his inventor Fabio Maulo. I’ve learned a lot with Fabio and Gustavo Ringel about CpBT.

A word about data binding

In this series of post we will make intensive use of WPF data binding capabilities. Is for that reason that I’ve written uNHAddIns.WPF that uses NHibernate extensions points to bring us few behaviors that we need for data binding.

The interface that we have to solve

The user need this very complex GUI. The user-story is as follows:

The user can have multiple instances of this window open for editing albums of different artists.
The user can add albums.
The user can add tracks to the new albums and preexistent albums.
None of the information is persisted until the user press “Save All”.
If the user press close the application will ask to the user if he really want to discard all changes.

This is all for now, in the next post I will talk about the architecture that I will use.