NHibernating with interfaces as entities, pt. 1

No catchy title this time:P
Have you ever considered using interfaces as entities in your application with NH as ORM? If not, and you never considered this option I can share a few thoughts about it with you.

Proxifing an interface is easier than proxifing a class, especially when using a tool like DynamicProxy which as far as I know still does not has this ability (yep, I’ve read about it on Kozmic’s blog). Why on earth proxify each entity you may ask? During the last project I was involved in, my colleague wanted to ensure, that setting properties and calling methods of one entity can be done only in explicitly set up scopes (explicit security). It’s quite easy when you can intercept all the setters and other, non-property method calls. All you’ve got to do is during instantiation of an entity wrap it with a certain proxy. What about instantiating entities’ implementations? There should be some, because it very unpleasant to have your entities only data oriented with no methods at all. This can be easily done with your implementation of NH’s IInterceptor. There is an interceptor method Instantiate(string entityName, EntityMode entityMode, object id); which, with help of your favorite container, can be turned into a entity factory. The code would look like this:

public override object Instantiate(string clazz, EntityMode entityMode, object id)
{
	if (entityMode == EntityMode.Poco)
	{
		var metadata = _sessionFactory.GetAllClassMetadata()[clazz];
		var type = metadata.GetMappedClass(entityMode);

		if (type != null)
		{
			var instance = _unityContainer.Resolve(type);
			var classMetadata = _sessionFactory.GetClassMetadata(clazz);

			classMetadata.SetIdentifier(instance, id, entityMode);

			return instance;
		}
	}

	return null;
}

The session can easily create the entity to hydrate it, we can be given our ISomeEntity with Load, Get, List. What about creating your entity for the first time? It can be also achieved providing an interface of IEntityFactory implemented with usage of the very same container used in the interceptor.
So far so good. But is there a catch? Yes there is and it’ll be revealed soon :)

How often do you micro-ing?

I did read about, I tried to used it, but the last InfoQ presentation about Microformats was simply astonishing. I do not like the Scott Davis’ style of presenting things, but it made me think… and the list of the biggest sites using microformats… Come on! It seems, that having your page highly ranked and being often found requires you to use it! Looking through the codeplex projects I’ve found a few analyzers but no extensions for ASP.MVC helping you to build a well-defined, full of micros site. What a shame ;-)

Simplicity of your architecture

A few days ago I watched a nice presentation published by Infoq called Simplicity Architect which made me think one more about design decisions I’ve been making through the last one year. Dan North, which was the speaker remind of the major problem every architect, I’d say, designer has. The problem is complexity lurking in the dark corners of each solution. I can remember times when from-zero-to-working-example took my team more than one month because of the db creation, design, and other stuff which you can qualify as things, which your business don’t understand. During the very last startup, it took me only 2 hours to provide the very basic set of functionalities with viewing and filtering a list of entities, editing them and so on. I did use a few tools (NHibernate, log4net, Unity and my infrastructure part injecting it all in MVC in my way), but it was only 2 hours to have a working example and it was _simple_ in terms of design. I did like it as the business owner did.

Hope you don’t get too complex either.

It’s getting cloudy, isn’t it?

I’ve just finished the Azure workshop. In two days course you cannot get everything, but as far as I know, the discussed topics can show what Azure is all about. I won’t rewrite plenty of blog entries and articles. What I want is to write that the cloud is the future. By the cloud I do not mean Azure, I mean the paradigm allowing you to scale as hell, to manage you site performance on the very organic level (“too much sugar – more insulin”). There is only one danger I can imagine and it’s not the security of your data. Imagine a situation that having such a scaling environment one can improve performance of his application with scaling rather then finding a bug running a 100 additional queries in each request. I hope that programmers’ culture will evolve and will disallow such behavior.

ASP MVC Model binders

Recently I had to create a model for ASP MVC, which would be bound by the model binder and had its properties set according to the request. It’s the most common case you can imagine, but there was one ‘but’. The model, because of its nature had to have non-default constructor. It was only a few parameters but it broke the DefaultModelBinder, which simply couldn’t find all the needed values. My response was quite fast, specially having the controller factory implemented in the following way:

/// <summary>
/// The controller factory building up the controllers with the unity container.
/// </summary>
public class ControllerFactory : DefaultControllerFactory
{
    private readonly IUnityContainer _container;

    public ControllerFactory(IUnityContainer container)
    {
        _container = container;
    }

    protected override IController GetControllerInstance(RequestContext requestContext, 
        Type controllerType)
    {
        return (IController)_container.Resolve(controllerType, null);
    }
}

The very next step was to replace the default binder stored in ModelBinders.Binders.DefaultBinder with another, controller-based implementation:

/// <summary>
/// The model binder building up the model objects with the unity container.
/// </summary>
public class ModelBinder : DefaultModelBinder
{
    private readonly IUnityContainer _container;

    public ModelBinder(IUnityContainer container)
    {
        _container = container;
    }

    protected override object CreateModel(ControllerContext controllerContext, 
                                          ModelBindingContext bindingContext,
                                          Type modelType)
    {
        var type = modelType;
        if (modelType.IsGenericType)
        {
            var genericTypeDefinition = modelType.GetGenericTypeDefinition();
            if (genericTypeDefinition == typeof (IDictionary<,>))
            {
                type = typeof (Dictionary<,>).MakeGenericType(modelType.GetGenericArguments());
            }
            else if (((genericTypeDefinition == typeof (IEnumerable<>)) ||
                      (genericTypeDefinition == typeof (ICollection<>))) ||
                     (genericTypeDefinition == typeof (IList<>)))
            {
                type = typeof (List<>).MakeGenericType(modelType.GetGenericArguments());
            }
        }

        // in the base method: return Activator.CreateInstance(type);
        return _container.Resolve(type, null); 
    }
}

As you can compare, the method simply delegates creating model to the container. Having this binder set allowed passing models with non-default constructors, so the problem was solved:] After a while, I considered following case: if the type is constructed with a container, the controller can also be passed an object implementing an interface registered in container. Hence, if a method needs a NHibernate ISession, this can be expressed not only as a parameter in Controller constructor, but also as a method parameter. This paradigm creates controllers with no parameters needed in constructor (or only common parameters, used in all actions) and all the others passed as action parameters. The result is a method, which can be perfectly tested in an environment where the only smallest, needed set of dependencies is passed (no more constructors with not needed in the current method parameters). What do you think about it?

An example of a controller:

public class CarController : Controller
{
    private readonly ISession _session;
    private const int PageSize = 10;

    public HomeController(ISession session)
    {
        _session = session;
    }

    public ActionResult Rent(IUserService userService, Guid carId)
    {
        using (var tx = _session.BeginTransaction())
        {
            var car = _session.Load<Car>(carId);
            var user = userService.GetCurrentUser();

            car.RentBy(user);
            
            tx.Commit();
        }

        return View();
    }

    public ActionResult Index( int? pageNo)
    {
        var page = pageNo ?? 0;

        var cars = _session.CreateQuery("from Car")
            .SetFirstResult(page*PageSize)
            .SetMaxResults(PageSize)
            .Future<Car>();

        return View(cars);
    }
}

Project structure

I’ve been working on a few quite big projects recently. The first I was dropped into was designed a few months before my arrival and had the solution consisting of almost 60 projects. The references were cascading, with each project having all the previous referenced. The web project depended on all of the projects, and had nothing in common with terms like dependency injection, ORM, best practices. All the data access code was written with using SqlCommands with caching thrown in multiple places. The same with other blocks you can imagine such as validation, logging, gathering statistics, etc. Reviewing the code made me think about NIH syndrome.

The second project was designed to handle a lot of stuff, for instance lifetime management (a very special case) and  very domain specific workflows. The design was done in 80% when I entered the project. We tried to write not much code, using already provided frameworks for different purposes like: NHibernate, log4net, NServiceBus, Irony parser (for domain specific language). Then the first version was established, the solution had 16 projects. Two weeks ago I made a major refactorization, reducing a few service and code-based (yet another abstraction) boundaries, creating a more integrated, yet _not_more_ coupled system. The final solution was performing better and had much simpler deployment. It consisted of 11 projects.

The very last solution consisted of 6 projects:

  • Web (having reference to NHibernate and Model)
  • Web.Config (infrastructure stuff, all the DI registrations, referencing all libraries and setting up controller factory in ControllerBuilder and default ModelBinder, infrastructure service implementations)
  • Model (entities, factories, services, types – like email, domain events and their handlers)
  • Model.Impl (implementation of interfaces from Model split in the Model’s manner)
  • Model.Persistence (all the NH event listeners, Fluent NH mappings, Solr services)
  • Model.Presentation (simple denormalized readonly objects to be used for queries result, possibly with Solr)

Do my solutions become to minimal? As far as the last solution is being built it does not seem so. The responsibilities are clean and all can be easily put into this separation. How do you find it? Any ideas?

Themis wants you to hibernate her!

Recently, I’ve been working on project which in the near future will have a quite complex authorization rules. Additionally, these rules will affect the display, simply filtering data sets, which one can view. Instantly I thought about Themis and it’s ‘future feature’ allowing to integrate with NH. What I’d like to have is simple Themis’ role definition:

public class AnalystRoleDefinition : BaseRoleDefinition
{
    public AnalysRoleDefinition( )
    {
        // CanView - helper method introduced in the application, wrapping Themis': Add blah blah
        CanView<IProtectedDocument>((document, analyst)=> document.ProtectionLevel <= analyst.AllowedProtectionLevel);
    }
}

Ok… As I can see, each analyst is given permission to view protected documents ONLY when he/she has AllowedProtectionLevel greater than document. According to Themis’ functionality it’s simple to create a service configured this way and check, whether in the context of a specified document this permission is granted. But what about filtering? If the analyst is disallowed to view such a document, shouldn’t it be hidden?

NHibernate filters to the rescue

NHibernate filters can be used to add specific conditions to querying classes and their collections. Being given the role definition mentioned earlier I could add filter with an easy condition (the analyst property would be a parameter got from the context, the real condition is based on a document ProtectionLevel column) for each class implementing the IProtectedDocument and activate them with one call based on the context. My very first proposal for API would be:

var roles = _roleService.GetCurrentUserRoles();
using(var filter = _nhAuthorizationService.ApplySessionFilters(_session, roles)
{
    var q = _session.CreateQuery("from IProtectedDocument");
    // other query stuff
}

The filter wrapped in using is an applier of filters which uses ISession.EnableFilter during creation and ISession.DisableFilter to undo filtering. It leave the session in a untouched filtering state.

If you bothered with explicitness and you want something implicit, you can easily add this behavior to your DI and never thing about it again.

Any thoughts about it?