My dear Italian readers ... our User Group reaches the fatal number too...we were tempted to skip it, but we couldn’t resist the challenge! So once again in collaboration with the Ce.S.M.I. of the University of Ancona we take part in the Microsoft Community Tour 2010.
The event will take place 1st December 2010 and will be hosted at the ‘Aula Magna "Guido Bossi" - Università Politecnica delle Marche - Facoltà di Ingegneria - Via Brecce Bianche - Ancona’.
This time we’ll see what await us when it comes to talk about:
Developing Windows Phone 7 applications (Roberto Cavallini and Roberto Brunetti)
Internet Explorer 9 and HTML 5 (Roberto Cavallini)
Windows Azure (Roberto Brunetti)
Reactive Framework (Diego Guidi and Andrea Nasoni)
Plus we’ll have an interesting lab session in which you can try your custom written WP7 applications on real production devices.
Since when I started using ConfORM to map my domain entities I felt the need to have something that showed me what type of mappings it generates; you can easily write tests and export the XML generated mappings (you have examples on how to do this in the ConfORM source code sample projects), but I wasn’t very confortable with that solution so I started writing my own mapping explorer utility.
Some of the key requirements I set are:
The ability to instantiate and configure ConfORM the same exact way it work in your project.
The support for mixed mapping techniques (that is part of the domain mapped in XML, as I wrote in my previous article).
It should work without a real database connection (for the basic set of features).
You should not be required to run your application, just point to the assemblies that contain the mappings.
It should not lock the assemblies when executing, so you are free to change and recompile the codebase with the ToolBox still open.
Minimal set of features:
Point to a folder containing a set of assemblies to explore.
Discover all the mappings available in the assemblies (even embedded XML files mappings).
Show each mapped entity and its corresponding mapping.
The ability to show all the mappings in a single view or navigate between them.
Show the database SQL generation script.
Show NHibernate logs and errors while generating the mappings.
This is the very first drop of my ToolBox Mapping Explorer, it’s like an early development preview and many options are hardcoded (you cannot change the target database type for example, it’s actually stuck to SQL Server 2005), but nonetheless it works. Here’s how the thing looks like right now:
Its usage is quite intuitive: point to a folder containing the set of assemblies you want to examine, hit the ‘Process’ button to discover the defined domain mappers (more on this in a minute), then hit the ‘Show Mapping’ button to start processing and show the mappings.
After that you can start looking at your mappings (it will show only the automatically generated ones at the moment, any predefined XML mapping will not be displayed) and at the database generation script; if you encounter any error, detailed exception information will be reported in the log box and in the related information box.
Let’s see how a domain mapper is discovered: this utility is still a bit invasive when it comes to define a domain mapper, in fact to be used it requires that your ConfORM initialization phase is wrapped in a class that implement the following interface:
public interface IDomainMapper
{
HbmMapping HbmMapping { get; }
When you have the need to modify or change your NHibernate mappings at runtime the obvious choice would be to go for one of a new generation mapping engine (like ConfORM, Fluent NHibernate, or anything else), but what about you plain good old XML mapping files you still use?
Changing them was a nightmare before NHibernate 3...I gave up on the task when I thought I had to pre-load the XML files, parse them, modify them in memory and the feed them to NHibernate; these operations seemed too long and too ‘hacky’ for a task that should have been simple.
NHibernate 3 comes to the rescue and offers a nice couple of events you can use to inspect and change your mapping before and after they are accepted and bound to be used by the configuration object:
BeforeBindMapping(object sender, BindMappingEventArgs) - this event is raised before the mapping is actually tied to the configuration object, you can inspect the mapping properties and change their values. Once the mapping is bound it becomes immutable.
AfterBindMapping(object sender, BindMappingEventArgs) - this event is raised after the mapping is bound to the configuration object, you can use it to inspect the metadata and get some information.
Using these events you have a chance to alter the mapping (acting directly with the NHibernate metadata structures) at runtime, whatever is the mapping method you chosen; in fact these events will be fired when you add the mappings to the NHibernate Configuration object via configuration.AddAssembly(), configuration.AddDeserializedMapping() and so on...
All the information are encapsulated in the BindMappingEventArgs class, which is something like this:
public class BindMappingEventArgs : EventArgs
{
public NHibernate.Dialect.Dialect Dialect { get; private set; }
In the previous articles of this series we saw how to initialize the ConfORM engine and how we can use it in an already existing project that make use of XML files to map the domain.
This time I would like to show you how you can customize some aspects of the generated mappings. One of the first things you will always need is to define your own patterns to give names to tables and fields so they can respect your conventions; I will use this scenario as a basic example to show you how flexible ConfORM is when it comes to define the shape of your mappings.
ConfORM works by discovering patterns through you domain model and applying customizations to what it’s able to identify, let’s take a look at the interface involved in the process:
IxxxMapper (IClassAttributesMapper, IPropertyMapper, etc...): ConfORM exposes a series of objects used to define each and every aspect of the mapping, they are used to set tables and column names, types, precision, etc...You have a mapper for almost everything from classes, id fields, types of relationships between entities...they are simply too many to be listed here, so take a look at the source code.
public interface IPattern<TSubject>
{
bool Match(TSubject subject);
}
Working with the new NHibernate Linq provider I needed a simple way to dynamically buildup a ‘filtering’ lambda expression to be used as the where clause in a select operation; nothing you cannot already do with the ICriteria/QueryOver API or with HQL...but I thought it would be cool to have the same feature with the Linq provider.
This way I can maybe reuse part of the filtering expression for in memory elaborations, create my EQO easier uing Linq to NHibernate or I can change it on the fly in other layers of the application (maybe not the best practice when it comes to data access strategies, but nonetheless it’s a feature you can use in some sceneries)
Currently concatenating expressions using an ‘AND’ operator isn’t that difficult: all you have to do is to keep calling ‘Where(Func<T, TResult>())’ before your non deferred operators.
In the last post we saw how to put ConfORM in action, this time..before digging into what you can do with it I would like to solve a problem that you (like me) will surely have to face if you plan to use ConfORM in a pre-existing project.
Let’s consider the typical scenario: you already have NHibernate up and running, but all your mappings are actually done using the standard XML mapping technique (which I still recommend to use when dealing with legacy databases). Now you need to extend the application and you have full control over the new tables that will be added, you don’t want to loose too much time rewriting all your mappings during the development stage; ConfORM is well suited to map this portion of your domain.
The main problem is that you do not want to touch what’s already working too much (that is you do not want to rewrite all your mapping to use ConfORM along all your application, because you have to define too many exceptions), plus some of your new classes can have references to portions of the domain mapped as XML and vice-versa...the question is: can I use a mixed mapping technique ?
The answer is: YES! Thanks to NHibernate and ConfORM great flexibility. Let’s see how modifying the example I had in my previous post.
Our domain consist of the following classes mapped using ConfORM: Person, Adult and Child.
We introduce a new entity called ‘Alien’ that we will map using XML file, and we’ll define some relationship between this class and the previous ones.
Here’s how we change the domain:
public class Alien
{
public virtual int Id { get; set; }
