Fluent NHibernate is my favorite extension for NHibernate. I am using it since early betas and I have to say that I love it. One of its underestimated features are conventions. I decided to extract some of them from one of my projects and provide real life examples how they can be used. My conventions are listed below but if you need more information visit Fluent NHibernate Wiki where this feature is described in detail.
ColumnNullabilityConvention – says that if nullability for column has not been specified explicitly, should be set to “NOT NULL”.
public class ColumnNullabilityConvention
: IPropertyConvention, IPropertyConventionAcceptance
{
public void Accept(IAcceptanceCriteria<IPropertyInspector> criteria)
{
criteria.Expect(x => x.Nullable, Is.Not.Set);
}
public void Apply(IPropertyInstance instance)
{
instance.Not.Nullable();
}
}
CreatedAtPropertyAccessConvention – says that every property named CreatedAt should be accessed through camel case field hidden behind it.
public class CreatedAtPropertyAccessConvention
: IPropertyConvention, IPropertyConventionAcceptance
{
public void Accept(IAcceptanceCriteria<IPropertyInspector> criteria)
{
criteria.Expect(x => x.Property.Name == "CreatedAt");
}
public void Apply(IPropertyInstance instance)
{
instance.Access.ReadOnlyPropertyThroughCamelCaseField(
CamelCasePrefix.Underscore);
}
}
ForeignKeyConstraintNameConvention – says that name of every foreign key constraint representing one to many relation should consist of names of entities for which it was specified.
public class ForeignKeyConstraintNameConvention
: IHasManyConvention
{
public void Apply(IOneToManyCollectionInstance instance)
{
instance.Key.ForeignKey("{0}_{1}_FK".AsFormat(
instance.Member.Name, instance.EntityType.Name));
}
}
ForeignKeyNameConvention – says that name of every column containing foreign key id should consist of name of type which it points to with “Id” suffix.
public class ForeignKeyNameConvention : IHasManyConvention
{
public void Apply(IOneToManyCollectionInstance instance)
{
instance.Key.Column(instance.EntityType.Name + "Id");
}
}
PrimaryKeyNameConvention - says that name of every column representing primary key should consist of entity name and “Id” suffix.
public class PrimaryKeyNameConvention : IIdConvention
{
public void Apply(IIdentityInstance instance)
{
instance.Column(instance.EntityType.Name + "Id");
}
}
ReferenceConvention – says that name of column referenced in many to one convention should consist of entity name and “Id” suffix.
public class ReferenceConvention : IReferenceConvention
{
public void Apply(IManyToOneInstance instance)
{
instance.Column(instance.Property.PropertyType.Name + "Id");
}
}
StringColumnLengthConvention – says that if length for string column has not been specified, it should be set to 100.
public class StringColumnLengthConvention
: IPropertyConvention, IPropertyConventionAcceptance
{
public void Accept(IAcceptanceCriteria<IPropertyInspector> criteria)
{
criteria.Expect(x => x.Type == typeof(string))
.Expect(x => x.Length == 0);
}
public void Apply(IPropertyInstance instance)
{
instance.Length(100);
}
}
TableNameConvention – says that if name for table has not been specified, it should be created using concatenation of entity name and “s” suffix.
public class TableNameConvention
: IClassConvention, IClassConventionAcceptance
{
public void Accept(IAcceptanceCriteria<IClassInspector> criteria)
{
criteria.Expect(x => x.TableName, Is.Not.Set);
}
public void Apply(IClassInstance instance)
{
instance.Table(instance.EntityType.Name + "s");
}
}
At the end the most important thing which shows that such conventions make sense. With default Fluent NHibernate conventions DDL generated by NHibernate for MySQL looked like this:
alter table `Athlete` drop foreign key FK9221C9B94070A6F0
drop table if exists Countries
drop table if exists `Athlete`
create table Countries (
Id INTEGER NOT NULL AUTO_INCREMENT,
Name VARCHAR(255),
primary key (Id)
)
create table `Athlete` (
Id INTEGER NOT NULL AUTO_INCREMENT,
DisplayName VARCHAR(255),
Email VARCHAR(255),
Password VARCHAR(255),
CreatedAt DATETIME,
IsActive TINYINT(1),
Country_id INTEGER,
primary key (Id)
)
alter table `Athlete`
add index (Country_id),
add constraint FK9221C9B94070A6F0
foreign key (Country_id)
references Countries (Id)
When I have applied conventions mentioned above to my fluent mappings DDL looks like this:
alter table Athletes drop foreign key Athletes_Country_FK
drop table if exists Athletes
drop table if exists Countries
create table Athletes (
AthleteId INTEGER NOT NULL AUTO_INCREMENT,
DisplayName VARCHAR(100) not null,
Email VARCHAR(100) not null,
Password VARCHAR(100) not null,
CreatedAt DATETIME not null,
IsActive TINYINT(1) not null,
CountryId INTEGER,
primary key (AthleteId)
)
create table Countries (
CountryId INTEGER NOT NULL AUTO_INCREMENT,
Name VARCHAR(100) not null,
primary key (CountryId)
)
alter table Athletes
add index (CountryId),
add constraint Athletes_Country_FK
foreign key (CountryId)
references Countries (CountryId)
For me it looks much better. Additionally I have made it once and that is it. Now I have to care only about domain model and business logic without thinking about not so important stuff lake names of database objects.
One of the new features introduced in C# 4.0 were named arguments. There was a lot of discussion in the Internet about them and theirs pros and cons. Of course named arguments can be abused like any other part of C# but I think that when used wisely are able to make your code more readable and easier to understand without the knowledge what is hidden behind the scene. Few days ago I was working on integration tests for REST API exposed by a startup I am working on with my team. Each test required some “execution context” and a way to inform “infrastructure” that after execution whole environment should be cleaned up (e.g. database). Because I use NUnit as a runner the first idea that came to my mind was to utilize [SetUp] and [TearDown] methods. But after some prototyping I realized that the solution is hard to understand and obfuscates the tests. Next day after short chat with @lesnikowski new idea popped into my mind: I can create “execution context” with lambdas and named arguments! The example below shows how I have changed the idea into real code.
I mentioned somewhere in previous posts I am playing a little with 
