Its hard to see the “death” of the relational database right now. I don’t think a switch-over from relational databases to non-relational databases is coming – but there is a game changer coming; another new technology getting a lot of buzz and traction in the blog world: Cloud Computing. I think the biggest driver in changing from relational to non-relational databases will be The Cloud.

Microsoft, Oracle, Google, Amazon, RedHat, JBoss, Ubuntu, Rackspace and many others are starting to provide cloud computing hardware, operating systems and hosting services. Cloud computing provides cost effective scalability and resource sharing for web applications. Looking at three of the main cloud contenders out there, Amazon Web Services, Google AppEngine and Microsoft Azure you see three common components:

1. Scalable Computing / Web Hosting computing
2. Scalable File Storage
3. Scalable Database Storage

The first two are pretty obvious and typically similar to traditional architectures, or not that different – however the Database storage is where things change: all three (Amazon, Google, Microsoft) have non-relational engines! While Amazon and Microsoft also have a cloud relational database, each comes at a different cost.

I see Amazon SimpleDB, Google’s BigTable, Windows Azure Storage Tables and others being a big NoSQL driver because of their price and scalability features. Once enterprises start moving into the Cloud and onto Cloud services I think we will see more architects evaluating and pushing for NoSQL.

I know the Unit Testing drum has been beaten for years, so instead of getting on a soap box and berating the Internet for not Unit Testing, I’m going to give you a story about a recent project I worked on, and how unit testing helped me succeed.

It all started last fall when I started work at a new client’s office. I opened the project from VSS and red flags started popping up. The first red flag was that this was a Visual Studio 2005 project and I was using Visual Studio 2008 (they did not install VS2005 on my computer), but this wasn’t really a problem – I was assured that they had standardized on Visual Studio 2008 now and the .NET Framework 3.5. The second red flag was the five projects in the Solution that couldn’t be found in VSS – each one ending with .Tests. I still don’t know why they were removed – but my guess is that they were removed because they didn’t pass.

The first thing I did was create a new Unit Test project. After examining source code thoroughly I created a test harness of unit tests of the existing functionality of the project. This is a very difficult and risky task since these tests are built under the assumption the current code works correctly! This is not a safe assumption when projects are missing from the solution. However, the fewer behavior changes I introduced to a program already in production use the better.

During this period (probably one week) I uncovered and fixed many bugs. I re-factored a lot of code. I did more testing.

Then I added my new functionality, retested and it worked.

I added more tests. They went from red to green.

My confidence grew with each little green light.

I added integration tests to the unit tests. These all passed.

Eventually the program was ready for deployment to the testing server (UAT – User Acceptance Testing) – a model of the production environment. And I was confident! My tests were passing!

This is when everything went wrong.

The Problem? Updating to the .NET Framework 3.5. Of course I had been misled when they assured me that they standardized on 3.5 – the production environment was still very much in 2.0 (and I was strongly assured they would not upgrade – even though I hadn’t asked).

The Solution? Unit Testing! I had extensively used the new productivity features of 3.5 like LINQ and Extension Methods. It took some rewriting and work but I was able to revert and rewrite everything back to 2.0 compatibility in one afternoon! The only reason I could do it so quickly was the unit tests I wrote that told me the functionality was still there and working in the old Framework. It took more time to find another computer with Visual Studio 2005 and the .NET Framework 2.0 installed (and not the 3.5 installed at all) than it took to rewrite the app to the older framework version.

There were more problems that were solved with more testing, but Unit Tests saved me a lot of time and guessing. There were some other things that could have made the project more successful such as better communication with other developers and the production team. Those issues were beyond my control. But I was so glad I had those unit tests, they saved my bacon. They gave me confidence in the completed software. The Unit Tests were also something I could show my client, the maintenance teams, and the testing teams in terms of functionality assurance for them.

Ah success! A new project! Another Solution! …and guess what? No unit tests. *sigh* Here we go again!

XML Files

Most of the ORMs I’ve used required a lot of configuration in XML files. Probably the worst offender in this sense is NHibernate. L2S, EF and DataSets are bad too, but at least they have tooling in Visual Studio to make it easier to use and hide the XML from you. In this respect, the Fluent NHibernate project is a life-saver for anyone using NHibernate.

POCOs and the Repository Design Pattern

Another thing most ORMs provide you with is an ability to use simple POCOs or Plain Old CLR (or C#) Objects. Ordinary DataTables and Strongly-Typed DataSets come with a lot of extra “clutter” to them, this is especially visible when you’re interacting with them using IntelliSense inside Visual Studio. The clutter appears as all the baggage that comes along with DataTables, as well as the fact you have to use DataAdapters, and fetch row objects (i.e. UserTableRow).

It is really nice to just have a simple class that can do what you need it to within the “domain” (following the Domain Driven Design ideas). It simplifies your data layer model significantly, and of course reduces a lot of clutter.

NHibernate and SubSonic are the clear leaders here, NHibernate even more so, but SubSonic can regenerate mappings after you’ve made changes to your database.

Simple Database Schema Creation

Another thing I like to see in an ORM tool is the ability to take your data-layer mappings and generate a database schema from that. The primary reason is that database versioning during development is hard. Keeping everyone on the same page with databases is difficult and making each developer use the same database is hard to impossible. If your ORM can just create and/or update your database schema for you off the bat, keeping each developer up-to-date is a breeze. No more “why is my app crashing?”, “where is that SQL script?”, “who did this?” shouting over the cubicle walls, instead you just run the update scripts and you’re all set.

As far as I know there is only one clear winner here and that is NHibernate; L2S, EF and Strongly-Typed DataSets don’t have this functionality at all. I believe that the 3.x version of SubSonic does have this now, and version 2.x had a version of migrations (that may be obsolete in version 3).

My Pick for Best ORM

I’ve personally switched from the SubSonic camp to the NHibernate camp in the last year. With Fluent NHibernate and guidance from the S#arpArchitecture projects all real difficult barriers into NHibernate have fallen. SubSonic is an awesome ORM and does help you get up to speed quickly, but it does feel like it isn’t developer or maintained quite as much as NHibernate is, and the differences between 2.x and 3.x versions was so great as to almost be intimidating to me (almost)!

Entity Framework is good, but I’ve had problems with the tooling and updating the mapping schema in the projects I’ve used it in. To me, there is very little programmatic difference with Linq-to-SQL, in fact EF seems to have more functionality. According to what I’ve read, it will have Database Schema Generation in the .NET 4.0 version, but NHibernate 2.1 already has LINQ support (via another library) so EF is really still just playing catch-up.

Strongly-Typed DataSets are pretty much an obsolete technology as far as I’m concerned – from the .NET 1.0/1.1 days. They do provide some simplification over bare metal ADO.NET, but I don’t find them as easy to use as NHibernate or any of the other ORMs I’ve discussed so I’ve seen little benefit in modern projects.

Summary

While I know there are more options out there than just the ones I’ve pointed out, NHibernate is the tool that best represents what I’m looking for in an ORM.

I didn’t actually speak to the developers myself, but my friend sent me an MSN transcript of their “discussion”.  Apparently tempers grew quite hot!  I did read most of the discussion and spoke with my friend to learn more about the system.

It turns out there would be many transactions with the database and web service coming from these devices with a fair bit of geographic data that had to be processed at the server.  One developer felt that using a web service would  involve too much XML/SOAP overhead and wanted to write his data as XML to the database directly.

I was not in favor of this suggestion.  A web service makes perfect sense in a .NET situation.  It denotes a logical boundary between applications and computers, and would be pretty obvious to any supporting developer what is going on.  Usually two applications do not share the same database (maybe the same server, but not the same database).   This increases complexity.

I was also not convinced that the “overhead” of the SOAP would actually limit the application.  Microsoft has done a lot to optimize web services.  They’re easy to develop now, easy to consume, and as I said: a logical boundary between systems.

In the end I strongly recommended that they do some benchmarking.  This early in the game is the perfect time to test assumptions.  I also recommended using one of the new Service Bus APIs out there that use technologies like Microsoft Message Queues if the web services are too slow.

Also, as Jeff Atwood recommended in his Coding Horror blog, sometimes it is cheaper to throw another $5000 server at the solution (even TWO servers) instead of paying two $70,000 / year developers to spend three-to-six months doing performance enhancements.