Monthly Archives: April 2014

Dynamic Runtime Binding is Awesome

This post is going to contain some content which will be relevant to a future post that I plan to do about my architecture for the HomeLibrary example application that I’m working on.

It involves using the dynamic runtime in .NET to do some pretty cool runtime binding.

First, a really quick example using the dynamic runtime. For those who are unaware of it, the dynamic runtime is not an alternative to the CLR, but something which runs on top of it and is able to provide dynamic binding, instead of the static binding which we are familiar with.

Take the following code:

dynamic someList = new List<string>();
someList.Add("I got added to the list");

foreach (var str in someList)
{
	Console.WriteLine(str);
}

someList = DateTime.Now;

Console.WriteLine(someList.ToString());

The two important principles, in my mind, which can be taken away from that are:

  1. you have dynamic typing, which resembles that which we see in Javascript;
  2. the methods which are invoked on those dynamic references are bound dynamically at run-time, as distinct from at compile time.

That second one is the one which really sets it apart from the var keyword.
var – compile-time binding
dynamic – runtime binding

As you could imagine, this opens up a raft of possibilities. I’m now going to show an example which is a good demonstration of how this can be used.

The problem which I will address in the next example is something very real and common if you want to decouple various objects in your architecture. Let’s say I have a whole swag of Validators. They all implement IValidator<T>. They do their work inside a method called Handle, which is a method on an single object called Handler. So, to clarify, there is not a discrete, strongly typed handler for each Validator. There is one handler which uses all Validators, depending on the command which is passed in to that Handle method.

If it were strongly typed, it would look something like this:

public void Handle(MyCommand command)
{
	IValidator validator = new Validator<MyCommand>();
	var result = validator.Validate(command);

	//  etc.
}

But as you can see, to make this work I’d have to create a Handle method for every single command which would each use their own validator. OR, I could do something like this:

public void Handle(TCommand command)
{
	Type validatorType = typeof(IValidator<>).MakeGenericType(command.GetType());
	
	var assembly = Assembly.GetExecutingAssembly();
	Type concreteType = null;

	foreach (var exportedType in assembly.GetExportedTypes())
	{
		if (validatorType.IsAssignableFrom(exportedType)) 
         		concreteType = exportedType; break;
	}

	var constructors = concreteType.GetConstructors();
	dynamic validator = constructors[0].Invoke(new object[] { });

	var validateResult = validator.Validate(command);
	
	//  etc.

}

You can see the Validate method is bound at runtime to the concrete object that is resolved by reflection. If the TCommand is a MyCommand object, then the Validate method of the MyCommand object is what will be invoked; and importantly no casting required.

And this code becomes even briefer if I use a dependency injection library:

public void Handle(TCommand command)
{
	Type validatorType = typeof(IValidator<>).MakeGenericType(command.GetType());
	
	dynamic validator =	_container.Resolve(validatorType); // _container is a private class-level variable

	var validateResult = validator.Validate(command);
	
	//  etc.

}

So you can see, the dynamic runtime becomes very useful when used in conjunction with reflection and/or your favourite IOC. This will greatly reduce the number of classes/methods you need to write, which alleviates the maintenance burden.

There is a trade-off. Use of the dynamic runtime incurs a penalty hit. On modern hardware, however, this is negligible. But if sheer performance is what is required by your application, then you may not be able to take advantage of the dynamic runtime (in the same way that you probably don’t want to use reflection).

A Slice Through the Layers

An index of the HomeLibrary application posts can be found here.

As I mentioned in my last Home Library post, I was eager to do a slice through the layers to test out any possible flaws or problems in my general architecture so far. To facilitate this, I fired up Balsamiq and created a View of roughly how I want one of the screens to look. The screen which manages people:
People

Note that all I want to implement here is the grid, not the whole screen. Also, I probably don’t need to explain the low fidelity nature of Balsamiq, which ensures that we don’t get too weighed down by such things as colour-selection.

The main things I want to verify in this exercise is:

  • whether I have configured Automapper correctly;
  • that my dependency injection is in order; and
  • that the data is making it from the database to the View as expected.

I created a separate branch to do this exercise, and as always with GIT, it’s very easy to make that available – LayersSlice Branch

Firstly, I created a service which will feed data to a presenter:

public class HomeLibraryService : IHomeLibraryService, IDisposable
    {
        private readonly IUnitOfWork _unitOfWork;
        private readonly IUniversalMapper _mapper;


        public HomeLibraryService(IUnitOfWork unitOfWork, IUniversalMapper mapper)
        {
            _unitOfWork = unitOfWork;
            _mapper = mapper;
        }

        public BindingList<UiModel.Models.Person> GetAllPeople()
        {
            var peopleRepository = _unitOfWork.People;
            PaginatedList<Person> peoplePaginated = null;

            peoplePaginated = peopleRepository.Paginate(0, 3);

            var uiList = new BindingList<UiModel.Models.Person>();

            _mapper.Map(peoplePaginated.AsQueryable(), uiList);

            return uiList;
        }

        public void Dispose()
        {
            //  This will be properly done in final code.
        }
    }

2 of the main things I want to verify can be ascertained right here. You can see that the parameters to the constructor are facilitating constructor injection by my dependency injection container. That is configured in my composition root, a.k.a. Program.cs:

    static class Program
    {
        private static IUnityContainer _container;

        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Database.SetInitializer(new HomeLibraryInitializer());
            new HomeLibraryContext().Database.Initialize(true);

            var autoMapperBootstrapper = new MapperBootstrapper();
            autoMapperBootstrapper.Initialize();

            ConfigureIoc();

            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new PersonView());
        }

        private static void ConfigureIoc()
        {
            _container = new UnityContainer();

            _container.RegisterInstance<IMappingEngine>(AutoMapper.Mapper.Engine)
                .RegisterType<IUniversalMapper, UniversalMapper>(new TransientLifetimeManager());

            _container.RegisterType<IRepositoryProvider, RepositoryProvider>(
                new TransientLifetimeManager(),
                new InjectionMember[] {new InjectionConstructor(new RepositoryFactories())}
                );

            _container.RegisterType<IUnitOfWork, UnitOfWork>(new TransientLifetimeManager());
            _container.RegisterType<IHomeLibraryService, HomeLibraryService>(new TransientLifetimeManager());

            PresenterBinder.Factory = new UnityPresenterFactory(_container);
        }
    }

The service also contains the code which I use to map a domain object to a Ui-model (objects which are more suited and shaped to the View for use in Viewmodels). With just two lines of code I’m able to map all of the properties from the domain’s PaginatedList to the Ui’s BindingList. Thank you Jimmy Bogard!

I’ve only created one View for this demonstration as I only needed to verify the slice through the layers. What you will see in the PersonView is that I have used the PresenterBinding attribute to bind the View to the PeoplePresenter:

[PresenterBinding(typeof(PeoplePresenter))]
public partial class PersonView : MvpForm, IPersonView
{
	public PersonView()
	{
		InitializeComponent();
	}

	private void PersonView_Load(object sender, EventArgs e)
	{
		dgvPersons.AllowUserToAddRows = false;



		dgvcDelete.Image = ImageResources.delete;
		dgvcEdit.Image = ImageResources.edit;

		dgvPersons.DataSource = ViewModel.People;
	}

	public event EventHandler ViewClosing;
	public event EventHandler EditPersonClicked;
	public PersonViewModel ViewModel { get; set; }

	private void dgvPersons_CellFormatting(object sender, DataGridViewCellFormattingEventArgs e)
	{
		switch (dgvPersons.Columns[e.ColumnIndex].Name)
		{
			case "dgvcIsAuthor":
				bool isAuthor;

				if (bool.TryParse(dgvPersons.Rows[e.RowIndex].Cells["dgvcIsAuthor"].Value.ToString(),
					out isAuthor))
				{
					e.Value = isAuthor ? ImageResources.tick : ImageResources.cross;
				}
				break;
		}
	}
	
	public void ReleasePresenter(IPresenter presenter)
	{
		PresenterBinder.Factory.Release(presenter);
	}

	protected override void OnClosing(CancelEventArgs e)
	{
		ViewClosing(this, EventArgs.Empty);
		base.OnClosing(e);
	}
}

WinformsMVP has 2 mechanisms for binding, that attribute and binding by convention. The reason I can’t use convention in my project is because my presenters will be located in a separate project which does not conform to the convention used by WinformsMVP to search for presenters. And that’s okay. It was a design choice I made. But if people prefer to bind by convention and to organise their projects in such a way that it conforms to that convention, then that’s okay too.

When the app is fired up, the following window loads:
PersonView

It’s not much to look at now, but this is just “proof of concept” time. The data is there and all is well for the plumbing, from top to bottom in the stack.

Note that a lot of the code in this post (in the branch referred above) will not look the same as I progress the project further. I have already moved forward and started putting in place the bootstrapping code in earnest.

Look out for a post in the near future which will talk about the query handling aspects of my architecture by virtue of the Mediator Pattern. Got to keep those presenters clean!

Underscore.js can Bind This!

underscore.js has a really neat method called bind that does something quite interesting. Let me first talk you through what that method is addressing.

One of the foibles in JavaScript is that the this pointer has a somewhat unusual behaviour in that it will point to the window object, when inside a nested function. Take the following example:

var car = {
	engine: 1,
	doorToWheelRatio: function (nrOfDoors){
		
		this.nrOfDoors = nrOfDoors;					
		
		return function (nrWheels) {
			//  'this' refers to window object in here
			return this.nrOfDoors / nrWheels;
		};
	}			
};

There are two instances of this. The second one being in the nested function. That function is not going to behave as expected because the this pointer is pointing to the window object. This is a known foible, especially in light of the fact that the previous this pointer points at the car object.

The historical way in which developers have overcome that is to assign the this pointer to another variable in the enclosing function (e.g. self), thus making it available in the nested function:

var car = {
	engine: 1,
	doorToWheelRatio: function(nrOfDoors) {
		this.nrOfDoors = nrOfDoors;
		var self = this;
		return function(nrWheels) {
		  return self.nrOfDoors / nrWheels;
		};
	}
};

Using underscore.js’ bind function, we can effortlessly bind the this pointer in that nested function to the car object:

var car = {
	engine: 1,
	doorToWheelRatio: function (nrOfDoors){
		this.nrOfDoors = nrOfDoors;

		return _.bind(function (nrWheels) {
			return this.nrOfDoors / nrWheels;
		}, car);
	}			
};

Now both instances of this are pointing at the same object, car.

When I say effortlessly, bear in mind it comes at substantial cost. Take a look at this benchmark which I have performed at perf.com which clearly shows that using bind is an expensive operation compared with using a local variable (as was historically done).

It would be remiss of me not to point out that jQuery also has an equivalent function called proxy. That code would look like the following if we were to use proxy:

var car = {
	engine: 1,
	doorToWheelRatio: function (nrOfDoors){
		
		this.nrOfDoors = nrOfDoors;					
		
		return $.proxy(function (nrWheels) {
			return this.nrOfDoors / nrWheels;
		}, car);
	}			
};

That is all.