Generic DAO with NHibernate and Autofac

Data access is one of the most important design decisions in software development. Depending on how you design your data access classes, every single modification causes cascading changes throughout your project. Imagine you have a lot of persistent data objects to manage and, for example, you have to change your database. This transition must be done without modifying the source code of your persistent classes. Other problem happens when you add more persistent data collection classes to the system. Of course, you won’t be happy if every time a new basic class is added, a new CRUD class is needed. The last point is programming in respect with the OOP, in other words, programming for the abstractions and not for implementations, with low coupling and high cohesion.

To solve those problems, the project that I’d worked for the last 8 months (Onibus Recife) used a combination of 3 technologies, and this post is about them.

NHibernate

NHibernate is an Object-relational mapping (ORM) solution for the Microsoft .NET platform: it provides a framework for mapping an object-oriented domain model to a traditional relational database. NHibernate’s primary feature is mapping from .NET classes to database tables. NHibernate generates the SQL commands and relieves the developer from manual data set handling and object conversion, keeping the application portable to most SQL databases, with database portability delivered at very little performance overhead.

NHibernate was used exactly for this purpose: create SQL commands and provide database portability.

Generics

Generics is a programming feature added in the .NET Framework 2.0 which allow you to define type-safe data structures, without committing to actual data types. This results in a significant performance boost and higher quality code, because you get to reuse data processing algorithms without duplicating type-specific code.

Using Generics, our team was able to use one, and just one, repository class for all of the simple persistent entities. Every time a new entity was add to the project, nothing more than its corresponding .hbm file was needed.

Autofac

Autofac is a fresh approach to IoC in .NET that fits well with C# 3.0.

The Autofac framework enabled us to inject all classes’ dependencies in just one place. So, when dependences changed, just a few lines of code were modified in a single source code file.

To illustrate those techniques, I’ll use them in a sample and small project.
Imagine a simple Contacts project used to keep your friends’ address, phone number and birthday. The abstraction of a contact is shown below.

Contact.cs

In order to persist the Contact class in my SQL Server database, I used NHibernate framework. Due to that, I need an .hbm file for the Contact class and a NHibernate session manager, responsible to manage database access. Because it’s a small and very simple project, I created a simple session manager, shown below.

NHibernateSessionManager.cs

Now, it’s time for the repository class. Actually, I implemented a repository interface and its implementation. Remember: program for abstractions, not for implementations. Note that they are generic. I did this to provide a single persistent implementation for more than one entity and simplify my life as a programmer. The code of them is listed below.

IRepository.cs

NHibernateRepository.cs

Now, let’s test our code reading data from the database. For that, I used the following piece of code.

TestReadContactById

The test passed, so everything is working.

Now imagine that we need another entity class, for example, a User, to restrict the program access with a username and password. All that I have to do is creating the User.cs abstraction and the User.hbm.xml file. I don’t need a new CRUD class for it. I just use the same generic repository that I used for Contact class, saving me a lot of time. Below is the code that I used to retrieve a user from the database.

TestReadUserById

Note that we must instantiate a new NHibernateRepository with a NHibernateSessionManager as parameter every time we need a new IRepository instance. Probably, in a big project, this line of code will be scattered in a huge number of files and, if that instantiation change for any reason, a lot of files will be modified. That’s what we don’t want. We like when changes are made in just one place and that is the work of Autofac framework.

Take a look of how the same tests are made using Autofac.

AutofacRepositoryTest.cs

The framework will inject all classes’ dependencies in the beginning of the program execution. Later, to instantiate an object, we ask the framework to resolve its type. If its instantiation changed, just the line of code where Autofac register is changed.

Conclusion

In this post, I’ve introduced a combination of NHibernate, Generics and Autofac. With these technologies in hand, I was able to create an extensible persistent layer in a low coupling and high cohesion way as shown in the sample project created.

For more information about this technologies see Hibernate and Autofac documentation.

See you.

–
Fernando

C# Extension Methods

I’ve been talking about Object-Oriented Principles for a while, and this post will not be different. Here and here, I’ve introduced OOP and described an elegant solution to comply with Open-Closed Principle using Visitor Pattern, respectively. Today I’ll be talking about a C# 3.0 feature called extension methods. Maybe you’re now asking what extension methods and OOP have in common. That is what this post is about.

Extension methods enable you to “add” methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type. For client code, there is no apparent difference between calling an extension method and the methods that are actually defined in a type.

Therefore, extension methods are an optional technique to extend classes functionalities without modifying it. This makes me remember the Open-Closed Principle which states that software entities should be open for extension, but closed for modification. By using extension methods, your software tends to be less difficult to change, to not impact in dependent modules and even more important, changes are achieved by adding new code, not by changing old code that already exists.

Extension methods are defined as static methods in static classes, but are called by using instance method syntax. Their first parameter specifies which type the method operates on, and the parameter is preceded by the this modifier. The following example shows extension methods for C# string class.

StringExtension.cs

Extension methods are only in scope when you explicitly import the namespace into your source code with a using directive. They are used as if they were instance methods and are visualized in VS intellisense, as show below:

Here is the test class for StringExtension.cs class showing how to invoke extension methods in C#.

TestExtensionMethods.cs

As you could see, this feature enables you to extend the string class, which is a sealed class, same as final class in Java, and implossible to inherit it. This helps you to extend and maintain code in a really elegant way. So, remeber using extension methods when find similar problems in you code.

See you,

–
Fernando