Based on my previous article Artem Smirnov[^] posted a question about how to test a Repository(DAL) method in a project using Nhibernate as ORM. Here is his question

"I wanted to unit test a similar, but more common, problem: a Repository method. I.e., create a test Order for a particular date, and test that the FetchOrdersByDate method returns this order if the date matches. My guess was that I could just create an Order, attach it to the session without saving it to the database, then somehow stub the database and make NH fetch it from the cache. After doing a lot of search, I discovered that this is impossible, so I had to hit the database for every test. Given that NH looks extremely flexible, i.e., Interfaces everywhere, this is kind of strange.."

Here is my answer

The problem related to testing a Repository method is a very common one and people suggest different solutions to this problem. Here are some of them

* Mock your Repository method by using a Mocking library or by hand. But this suggestion is not valid all of the time. If you have native SQL or use NH Transformers to produce DTO's mocking is not an option.

* Use an in-memory database like SQLite for your tests. But if you have native sql or develop against a legacy database or use part of a legacy database you can not follow this approach

* Take script of your production database and create an empty test database. Run your tests against the test database. This method also have some drawbacks, to name few, tests take longer to run, you have to keep your test database up to date with the live one, you have to deal with some phantom objects not directly managed by your domain ( for example your domain contains Instructor class just for integrity reasons and you do not have code to deal with Instructor instantiation because you do not actually need this piece of function. But somehow you have to create Instructor objects for testing). You can solve the first two problems with Continuous Integration, but the later can be tricky to solve. However this last approach has one big outcome, that is, you will likely have failing tests if something goes wrong with your database.

I personally tend to follow the last approach for NH specific testing and write pure unit tests otherwise. 

CodeProject

Download NHibernate.Caches.Testing.zip (24.75 kb)

Motivation

It has been a long time since the last time I dropped a new entry in my blog. I was very busy with our new project and at last we finished coding and moved to Acceptance Testing phase. That new project was a little bit challenging from architectural point of view. Some challenges to name were

• We had to develop against a legacy database
• We had to replace an existing system with a new one, it was a little bit problematic process to introduce some new concepts
• Our system was designed targeting a small part of the legacy database, hovewer that part was accessed by some external processes/systems bringing some synchronization issues.
• We placed very strict code coverage and testing goals

In this blog entry I will try to share a very specific problem, writing good tests for NHibernate Level2 caching related functionality, we experienced and how we solved that problem.
More...

Here is aother strange problem related with NHibernate

The Problem

I have a Parent class and two child classes Child1 and Child2 mapped to different tables on the database.
Lets assume that we specified cascade='all' for child bags defined on Parent.hbm.xml. Sample workflow of instantiating parent and child objects is as the following

- Create a parent object.
- Insert 2 Child1 instances to child1 bag
- Insert 3 Child2 instances to child2 bag.
- Flush the session
- Refresh parent object
- We get 6 instances for each child bag (child1 and child2). But we expect 2 Child1 instances in child1 bag and 3 Child2 instances in child2 bag.

Ther problem is : NHibernate performs left outer join on Child1 and Child2 tables when Refresh is called for the parent object. This is unaccaptable, I think NHibernate should initialize child collections with seperate selects commited to the database, or may be distinguish the duplicated child instances automatically in the collections. (using idbag instead of bag is not an option)

Download the test case

• NH1472.rar (1,12 mb)

Requirements

•  NHibernate.Burrow

Watch This

•  NH-1472

I discovered this problem while developing a new system with the latest NHibernate.Burrow distribution (which in turn uses the latest NHibernate distribution).I spent some time Googling around to check if anyboy else met the same problem and found some entries but none of them specified exactly why this failure was happening and how we can solve this problem.
More...

I've already developed some projects with NHibernate and I can say that NHibernate is a real time saver. But I must admit that it takes some time to get used to NHibernate. As an ORM NHibernate has fantastic features but if you want to develop successfull projects with NHibernate you must know that NHibernate is only one part (ORM) of a successfull layered architecture. In the attached solution I tried to give you the basic idea of a layered architecture and how NHibernate can be used within such an architecture

Attached solution includes the following projects

• Core: Our domain objects (entities) reside in this layer. Also DAO (Data Access Objects) interfaces are defined in this layer.
• DAL (Data Access Layer): Default implementation of DAO interfaces reside in this layer.
• BLL (Business Logic Layer): Business logic code resides in this layer.
• Common: Some utility calsses reside in this project
• Tests.Disconnected: Includes unit tests for domain objects and business logic. Notice that unit tests in this project do not require domain objects to be persisted (NHibernate behaviour will not be tested), so the need for a database connection is eliminated which in turn makes our unit tests fast. Notice how we replaced our default DAL with mocked one.
• Tests.Connected: This project includes unit tests too, but this time we want to test how our domain objects and bussiness logic perform NHibernate. NHibernate provides very cool features like native sql, lazy loading and cascading and we will likely want to test how our domain objects behave when armored with these cool features of NHibernate. It is also very likely that we will have some mapping errors (typos likely) in our Core, these tests will help us catch these errors. Performance bottlenecks possibly caused by our NHibernate mappings (for example we may discover that we need to make a child collection to be lazy loaded) can also be identified with help of these tests.

In the sample solution you can also find a simple usage of Castle Windsor Inversion of Control (IoC) container. We use IoC to be able to load different implementations of our DAL (DAO implementations). 

Another very important point you need to understand really well is session management of NHibernate when used in web applications. Thanks to Burrow contribution project this task is made very simple, you do not even need to write single line of NHibernate session management code. You only need to inherit your DAO implementation classes from GenericDao<T> class and you are ready to go. 

Additional Notes

• Database script is included in Tests.Connected project under DBScript folder. 
• Sample project uses NHibernate  2.0 Aplha1 and NHibernate.Burrow is also Alpha1.
• ASP .NET MVC Preview 3 to run Sales.MVC sample
• TestDriven .NET to run NUnt tests

Suggested Readings

• NHibernate Reference Documentation
• NHibernate Quick Start Guide
• NHibernate In Action  by Pierre Henri Kuaté, Tobin Harris, Christian Bauer, and Gavin King
  
• NHibernate Best Practices with ASP .NET by Billy McCafferty

Downloads

• SalesSample.rar (5,61 mb)

Update History

• 09 June 2008
  • Castle files under Libs folder updated to Castle RC3
  • SQLite references removed
  • TestFixtureTearDown override of CustomTestBase class in Sales.Tests.Connected assembly commented out

Introduction

Cuyahoga framework has very nice approach to Web development. It has bunch of built-in modules and you can develop your own modules in a
couple of hours. If you have some experience with NHibernate and/or some other web framework your module development
may even take less than an hour. My product site PragmaSQL Online runs on top of Cuyahoga framework and it took
me just a couple of hours to bring this site up and running. Although Cuyahoga is a very nice framework and I love Cuyahoga development
I shall admit that you may experience some problems while applying some advanced topics like Ajax to Cuyahoga. In this article
I will show you a simple and structured way to add Ajax support to your Cuyahoga web site.
More...

Audit logging is an important issue while building enterprise systems. Simplest form of audit logging is recording
who and when created/updated an object, or a record in the database respectively. We perform four basic operations
on a domain object. These are

Data access layer is a good place to perform automated audit logging
whenever one of the operations above is executed. NHibernate provides us with
IInterceptor interface plus ILifecylce interface. You can read this article for more
information about Nhibernate entity lifecyle management.

In this article we will try to perform simple logging that meets the
following minimal requirements

1- We will log who performed insert/update and when this operation was performed
2- Log data will be written to the same database and table as our domain object
More...

Motivation

PragmaSQL started as part time development effort and by time PragmaSQL evolved to a commercial product.
Today PragmaSQL has a dedicated web site (PragmaSQL Online) build on Cuyahoga Framework.
PragmaSQL Online was primarly designed to meet very simple requirements like

• Host simple advertorial content introducing PragmaSQL
• Host downloads ( PragmaSQL Application, 3rd party add-ins and other open source material)
• Licences distribution and validation via some web services.

As the number of people using PragmaSQL increased PragmaSQL Forum was added to enable users to communicate
with each other and with PragmaSQL developers. PragmaSQL forum was the only place where people submitted bugs,
support and new feature requests. But as the number of posts increased managing all this content became a real pain for
me. It was hard to group and keep track of the posts, for example i could not know exactly how many bugs were posted
and how many of these bugs are waiting, in progress or already resolved.
Forum approach to maintainance was also inefficient for the users , they had no clue about the status of their posts
because Forum Module did not provided custom post attributes and the communication model was very loose. Forum module
did not have any mechanism to notify users about the status changes of their posts.
More...

In previous CodeProject.com article NHibernate Best Practices with ASP .NET, Generics and Unit Tests by Bill McCafferty
Core project contains DAO interfaces and domain objects while Data project contains implemetation of DAO interfaces.
For performance reasons, since we do not want to iterate over collections to find a matching object, we use DAO and thus
NHibernate to query for objects we are interested.More...