public void Foo(IEnumerable<string> strings)
{
	IEnumberable<string> stringsInDb = strings.Where(s => this.QueryTheDbAndTakeALongTime(s));
 
	foreach(string str in stringsInDb)
	{
		//Where clause in LINQ is actually executed 
	}
 
	foreach(string str in stringsInDb)
	{
		//Where clause in LINQ is actually executed  AGAIN
	}
}

Luckily, some unit tests detected this behavior. It actually isn’t surprising when you think about it though. The proper thing to do for this case is actually call ToList() after the Where().

IEnumberable<string> stringsInDb = strings.Where(s => this.QueryTheDbAndTakeALongTime(s)).ToList();

Don’t let this behavior bite you.

This…

int count = 0;
foreach (string email in this.emails)
{
    if (email.EndsWith("@mydomain.com")) count++;
}
return count;

becomes this…

return this.emails.Count(email => email.EndsWith("@mydomain.com"));

In some weird kind of way, I feel like an emo Ruby developer. Maybe I’ll start wearing some tighter clothes.

To install for TestDriven.NET, just create an addins folder in the %install root%\TestDriven.NET 2.0\NUnit\2.4\ and copy NUnitExtension.RowTest.AddIn.dll to the newly created folder. Then in your test project, just reference NUnitExtensino.RowTest and you are set to go.

Here is an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

namespace TestExample
{
     [TestFixture]
     public class Tests
     {
          [RowTest]
          [Row(-4,4)]
          [Row(-5,5)]
          [Row(-6,6)]
          public void TestAddEqualsZero(int x, int y)
          {
               Assert.IsTrue((x + y) == 0);
          }
}

This is not the case though. The only time you really need a destructor is when a class directly contains unmanaged resources, like file handles.

A good example of when not to use a destructor is a wrapper class. For instance, if you have a database connection class wrapped with some sort of adapter class, the adapter class doesn’t need a destructor. It still needs to implement IDisposable to enable early disposal of resources, but the destructor of the underlying database connection class will handle any potential leak cases if Dispose() isn’t called.

Here is a quote from a very good article on C# traps:

The destructor should only release unmanaged resources that your object holds on to, and it should not reference other objects. If you have only managed references you do not need to (and should not) implement a destructor. You want this only for handling unmanaged resources. Because there is some cost to having a destructor, you ought to implement this only on methods that consume valuable, unmanaged resources.

The really powerful statement is “it should not reference other objects” which basically backs up my previous statement on wrapper classes.

Here is another good article on destructors and IDisposable.

Mailtrust has many different customers, some of which like to have their own branded control panel or webmail interface. We allow them to customize many different facets of the user interface, including colors. This has some unintended consequences though. Sometimes, a user might select a white font color on top of a white background. This in turns causes support to get involved in fixing the problem, which wastes time on such a trivial problem.

But there is a better way. Use trigonometry, or more specifically the Pythagorean theorem! I had no idea how this worked, but Dellanoce coded up a few lines of C# to compare two colors. It returns a distance value which can be compared to a threshold value you can set.

1
2
3
4
5
6
7
8
9
10
11

        private static double ColorDifference(string htmlColor1, string htmlColor2)
        {
            Color color1 = ColorTranslator.FromHtml(htmlColor1);
            Color color2 = ColorTranslator.FromHtml(htmlColor2);
 
            double rDiff = Convert.ToDouble(color1.R) - Convert.ToDouble(color2.R);
            double gDiff = Convert.ToDouble(color1.G) - Convert.ToDouble(color2.G);
            double bDiff = Convert.ToDouble(color1.B) - Convert.ToDouble(color2.B);
 
            return Math.Sqrt((rDiff * rDiff) + (gDiff * gDiff) + (bDiff * bDiff));
        }

I was quite impressed with the simplicity and elegance this solution provided. I should probably go give my, or his, trig teacher a hug.

If you want to learn more about how powerful Pythagorean theorem is to compare distance values of really any type of object, check this article out.

But what happens when you have code embedded in business logic that might not always be running in an ASP.NET web application? HttpContext isn’t valid, so you can’t use it. Why not use CallContext, since HttpContext uses this anyways?

I was starting to convert some of my code to use this, when I found this article. Apparently doing this works most of the time but can cause some nasty bugs since ASP.NET can switch HttpContext‘s without switching CallContext‘s.

Instead, code that could be called from ASP.NET and other applications should first check for context.

1
2
3
4
5
6
7
8
9
10
11
12

if(HttpContext.Current == null)
{
     //Using CallContext example since not in ASP.NET
     CallContext.SetData("blah", new object());
     object contextData = CallContext.GetData("blah");
}
else
{
     //Using HttpContext example since in ASP.NET
     HttpContext.Current.Items.Add("blah", new object());
     object contextData = HttpContext.Current.Items["blah"];
}

In fact, I will probably end up writing a static class to implement this so code doesn’t have to constantly check whether or not in an ASP.NET session.

Problem #1 – Downloading

Almost all the links to NMS point to Sprint.NET’s NMS build. If you notice the date in the link, the last time it looks to have been built is March 20, 2007. Also, almost all the links are broken on this site, which is never a good sign.

Instead, just download from Apache NMS . Since they don’t have releases, just checkout from SVN (https://svn.apache.org/repos/asf/activemq/activemq-dotnet/). Note that the link on their website points to (https://svn.apache.org/repos/asf/activemq/trunk/) which isn’t NMS.

Problem #2 – Application Hang

One issue that exists with the NMS library is a race condition when sending synchronous messages. Basically, when sending a synchronous message, if the transport connection dies after sending, the application waits forever. Luckily I found this article which tells you how to prevent it. The Apache NMS documentation doesn’t mention it, but there is a query parameter that can be added to the connection URI that will timeout synchronous calls. So the URI would look like tcp://myactivemqserver.com:61616/?transport.requesttimeout=10000.

Even though this fixed the problem, it annoys me because it is very easy to fix without having to use a timeout parameter. I am thinking about trying to get a patch applied to the library but until then, just email me if you want to know the fix.

Problem #3 – Transport layer death

Even though request timeout fixes multitudes of problems, I want to make sure that the connection is destroyed in the event of any error. It isn’t documented very well, but this ExceptionListener event will bubble up anytime an error occurs in the transport thread and the socket gets closed.

1
2
3
4
5
6
7
8
9

//Create connection
IConnectionFactory factory = new ConnectionFactory(uri);
this.connection = factory.CreateConnection();
 
this.connection.ExceptionListener +=delegate(Exception e)
{
     this.connection.Dispose();
     this.connection = null;
}

There are two problems with doing this though. One, it isn’t very thread safe because the delegate WILL get called from a different thread. NMS is a multi-threaded library and there is no way around this. Thread safety should be handled better, but this is a trivial example to show the concept of the ExceptionListener event. Two, this event will get called if ActiveMQ returns an Exception message, which sometimes aren’t fatal. Normally, I have only seen these when disconnecting so just detach the event handler from the event before closing the connection.

Don’t get my wrong, I know Java is a very widely used platform, but what has really changed in the past few years with Java? I might just be ignorant on the matter, but I haven’t heard of much. .NET on the other hand seems to be the face paced new comer when it comes to platforms for development. The feature-set in .NET Framework 3.5 is quite simply amazing. Not to mention, it supports a multitude of languages, soon to be including Python and Ruby.

But, I can’t entirely say I support .NET. The one thing that kills me is its ties to Windows. I know, Microsoft doesn’t have much of a reason to port it to other operating systems, but this gives Java a huge leg up. Even though Mono exists, it is barely keeping up with .NET Framework releases.

No matter which doctrine you subscribe to, competition is a good thing and will only make each platform better. I look forward to watching both closely over the next few years.

To all my Java and Linux friends, feel free to leave flaming comments.

Session Management

The biggest thing that I don’t like is the session management aspect. Although I have come to understand why NHibernate sessions are so valuable and critical to its functionality, it doesn’t stop the fact that persistent objects are tied to a single database. For a project that follows the patterns and practices set forth in ivory towers, this works great. All business entities are stored in a database in 6th normal form and everyone is happy. Well, when working with legacy and enterprise systems, that usually isn’t the case. There are many different databases that are used and objects are stored across a variety of them.

In order to get my system to use NHibernate, the first challenge was incorporating multiple sessions. A session is basically a connection to a single database that manages persistent objects. This article describes a really complex way to accomplish it, but all you really need to pay attention to is the NHibernateSessionModule and NHibernateSessionManager. Using the outline described in the article, I successfully got multiple sessions to work fairly painlessly.

The second challenge was storing a persistent object in multiple database. Since persistent objects in NHibernate can’t span multiple sessions, some data massaging has to be performed. As I see it, there are two possibilities for storing an object in multiple database.

1. Different objects for each database with type conversion operators
2. The same object for all databases with extra session logic

The latter is obviously easier from a domain model perspective, but not from an implementation perspective. For a persistent object from one session to be stored in another session, all references must be removed from the session. This means unproxying the object and unpersisting any collections contained within the object. Looking through the NHibernate source code, I was able to accomplish this with only a few lines of code.

Setup & Documentation

Most of the getting started guides for NHibernate are no where near complete or up-to-date. It took a couple days to get my environment up and running. This isn’t really a problem with the library itself, but is still a problem for first time users. In all reality, there seems to be a lack of documentation in general. Three example mappings in the documentation is no where near enough for what is marketed as an enterprise ORM solution.

Conclusion

NHibernate is awesome. Even with these minor issues, it is one of the greatest tools for web development I have ever used. I hope that the development of this library continues to improve, and hopefully some of these issues will be resolved.

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.