Today I ran into a few problems while writing test cases for NUnit. I kept receiving reflection errors and the exceptions were too vague to help me fix the problems. Luckily, I found an article on debugging while testing with NUnit. Works like a charm.
Update…
If you use TestDriven.NET you can just click on a project and use Test With->Debugger. It has the same effect and is much easier than the above article.
One of the greatest things about .NET, in my opinion, is the debugger built into Visual Studio. For a developer, a great debugger can’t be beat. Unfortunately, there are some cases that a great debugger can cause more harm than help.
Since I started using NHibernate, I got into the habit of tail-ing the MySQL query logs. I have written a lot of database access code, and still don’t trust NHibernate. I started noticing weird problems when I started using NHibernate’s Load() function. According to the documentation, no query should be performed in this case. But a query was occurring.
After some digging, I realized the debugger was calling the ToString() method on the object. Since the object is proxied, any access to it causes a query to be loaded. A simple setting in Visual Studio fixes the problem. Just uncheck Tools->Options->Debugging->Enable property evaluation and other implicit function calls. This will cause the code to act more like release code, but will make debugging a little harder since all properties can’t be accessed.
As most of you know, the data access layer is my favorite application layer to work with. For a while, I worked on my own active record implementation in PHP. After switching to .NET, my outlook has strayed away from the active record pattern though. I like using business entity objects that have no coupling to a database. Instead, I use an object/relational mapper to translate from business entity to persisted database object.
At first, I started working on my own implementation again, which provided a simple, in code, mapping technique. I quickly realized that mapping business entity relationships wasn’t easy though. After a couple hours of staring at my monitor hoping I could come up with an elegant solution, I decided to look at some 3rd party mappers. I had heard about NHibernate before and decided to give it a shot.
I spent about two days prototyping part of my database in NHibernate and my first impression is wow. Everything I could think of adding in an o/r mapper exists in NHibernate. Lazy loading, relationships, inheritance, component mapping, and so much more is possible. Over the past few weeks, my entire data access layer has been converted to NHibernate with overwhelming success. Like any library, it has its own quarks, but for the most part it speeds up development time while adding lots of power to my applications. I would recommend it to anyone.
NHibernate uses XML documents or .NET attributes to map an entity class to a database. I never thought I would use XML again after painful VB6 experiences, but I decided to give it another shot. To my surprise, I loved it. It allows for really clean separation of the database and code, which basically means cleaner code and a happier Brian. The only really annoying part of NHibernate is session management, but I’ll save that for part 2.