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.

Policy Injection is similar to aspect-oriented programming in that it helps to break away cross-cutting concerns (authorization, logging) from the actual business logic. And yes, I basically copied that from the documentation.

Here is what policy injection means for me. I can build business logic, which performs only what I want it to. So I can have a function called AddUser and all that is done is the actual operation of adding that user. I can then attach policies to that function, which specify how to authorize and log it. This has a couple effects. One, it reduces the amount of code which in turn cleans up the code. Second, it allows me to customize cross-cutting concerns for different projects. If I have an administrative application, I need to authorize differently than a user application. Policy injection makes this possible without dirtying up the code.

After the initial few hours of getting used to using it, I am a huge proponent. I definitely recommend checking it out.

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.

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.

The first symptom I ran into was a 503 Service Unavailable response when accessing the website from a browser. Checking the IIS error logs showed a AppOffline DefaultAppPool error description, not very helpful. The event log had a better message:

ISAPI Filter ‘C:\Program Files (x86)\Common Files\Microsoft Shared\Web Server Extensions\50\bin\fpexedll.dll’ could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.

Googling found two related articles, one on the 503, and another on the ISAPI issue.

The solution recommended running the following command:
CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

When this command was ran, nothing was fixed. I tried running the inverse, and setting to only allow 64 bit applications, and it worked.
CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

The Bad

ASP.NET, in my opinion, attempts to provide a RAD environment for developing new applications. DataSets, Membership, Roles, and Data-bound controls all show how ASP.NET doesn’t want the developer to waste time on mundane tasks. What I hate is the lack of flexibility with these approaches. For the same reason I dislike Rails, I dislike many of the extras ASP.NET has to offer.

For example, I don’t want to use the Membership API because I am porting an existing application to ASP.NET. Membership has a strict set properties a MembershipUser must have. This is inflexible. I don’t want to adapt my application to fit with Membership, I want Membership to adapt to my application. The same goes for many of the other tools in ASP.NET.

The Good

ASP.NET is a great foundation. It provides all the necessary tools to create a great web application. Although ASP.NET is a framework, it lets you pick the tools you need and want for your application. If you want to implement a custom authentication system, you don’t have to use Membership. If you hate DataSets, don’t use them.

For developing new Web 2.0 applications, I have no doubt that using all the built-in ASP.NET tools could greatly speed up development. For existing applications, or enterprise applications, many of the tools probably won’t work. But at least you have the option to pick and choose.

ADO.NET provides common interfaces and base classes that can be used with different database providers. While some companies use everything Microsoft, we do not. In all honesty, I would choose MySQL over SQL Server for almost any project but that is an argument for another day. Like I was saying, ADO.NET is good, but can have some very repetitive code. Managing connections, creating commands, adding parameters, and executing readers is pretty annoying. But, the worst thing about ADO.NET is having to create database provider specific code. To create a connection to an Odbc database, you have to actually load the OdbcConnection class.

Luckily, Microsoft realized that ADO.NET had these short comings and created Data Access Application blocks, which are part of their Enterprise Library. I have been using them for a couple weeks and am definitely a fan. The greatest thing about it is the ability to completely abstract out the database provider. For example (Copied from the Microsoft website):

Database db = DatabaseFactory.CreateDatabase();
DbCommand dbCommand = db.GetStoredProcCommand("GetProductsByCategory"); 

// Retrieve products from category 7.
db.AddInParameter(dbCommand, "CategoryID", DbType.Int32, 7);
DataSet productDataSet = db.ExecuteDataSet(dbCommand);

If you didn’t notice, there was no mention about an Ole, SQL, Oracle, or Odbc provider. Also, I think it is a really clean and logical way to abstract the database. I definitely recommend checking out Data Access Application blocks, as well as the entire Enterprise library.

After a few days of digging though, I found a few great articles (Choosing Data Containers for .NET, On the Way to Mastering ASP.NET: Introducing Custom Entity Classes) on why not to use DataSets, as well as why you should. DataSets were designed for rapid application development, and seems to be Microsoft’s answer to the Rails ActiveRecord pattern. It is a quick and dirty way to build the data access layer for web applications. To be more specific, by quick I mean it allows version 1.0 of a product to be released quickly, because a data abstraction already exists. By dirty, I mean it isn’t an abstraction created for your application, it is a data abstraction created for any application.

Pro’s of ADO.net

• Fast development time
• In place architecture.
  Developing custom data access solutions can be very powerful, and very risky. A bad design can lead to bad performance and is inherently error prone
• Feature rich
  • Disconnected data
  • Concurrency
  • Many more…
• Easily serializable

Con’s of DataSets

• Large memory footprint
• Not object oriented.
  DataSet’s represent relation data, just like a database. But I don’t want an in-memory representation of the Employee table, I want Employee objects. Scott Hanselman sums it up pretty nicely:

  A DataSet is an object, right? But it’s not a Domain Object, it’s not an “Apple” or “Orange” – it’s an object of type “DataSet.” A DataSet is a bowl (one that knows about the backing Data Store). A DataSet is an object that knows how to HOLD Rows and Columns. It’s an object that knows a LOT about the Database. But I don’t want to return bowls. I want to return Domain Objects, like “Apples.”

• Not abstracted.
  Directly connected with database data and structure. So, any change to the database schema, could trickle down to the presentation layer.

Conclusion

ADO.NET is a huge improvement from old ADO, but don’t buy into the entire framework. Microsoft is trying to push DataSets but they might not always be the best solution. For enterprise applications, I don’t think DataSet’s are the answer. On the other hand, for smaller web application, it might be a perfect fit.