Underused C# feature: string.Format and custom formatters

There are developers out there who get classified as being lazy. I got called being a lazy developer when adding an Extension method to decimal types to convert to some Html formatted string.

Example:


This makes the code look clean and is pretty simple to understand for any other developer to come in later and know what is being done. The problem is that other developers may consider this abuse or misuse of Extension methods. "Why should a decimal know how to convert itself into a certain type of string?"

Enter the string.Format method and a custom formatter. string.Format can take in any argument, a format, and custom formatter, then return you the string equivalent for that argument. Although I agree that this is a more appropriate approach that doesn't make it a cleaner solution. In my opinion only.

You would make the call like this:


Although it works and is the proper solution in this case, it's ugly.

I am open to other solutions to this scenario, so if you have a good solution please post in the comments.

Here is a full example of how to implement a custom formatter to use with string.Format.

Test Class (MS Test):


Custom formatter implementation example:

Linq to Xml Stress!

So it has been a while since I have written anything, but the issue I just over came was enough to write home about.

My task was to parse some Xml into an object. We all love using the new ways of doing things. I chose to use Linq to Xml. Now I have been using this method for some time now, making life parsing Xml quick and easy.

The problem that I came across was if you lack the control of what that Xml will look like and it is not properly Html Encoded. Linq to Xml does not include the InnerXml property that was once available on XmlElement.

After looking through every available method and property available on the XElement, I thought my life was over and was going to be forced to hack out a solution. The latter is still somewhat true, but the hack has been nicely implemented using an extension method called InnerText.

Below is the code used to generate the InnerText solution, this being the fastest of other solutions such as using a StringBuilder

NHibernate Schema Export Frustrations!

NHibernate makes schema creation quick and easy, but one situation I found annoying was that calling new SchemaExport().Execute() wouldn't drop the existing schema first. I found myself manually deleting the tables in the database in the correct sequence every time I wanted to blow away the schema and rebuild it.

Error


Through some Googling, I discovered that if you split the SchemaExport into multiple calls, you no longer receive the issue.

Before


After


It seems as though the Drop method doesn't have an issue on a fresh database, yet drops the database elements of they already exist.

Playtime with NHibernate and Spelling mistakes :(

So I have finally decided I have some time to take a look at NHibernate. My curiosity for the tool has as of recent, become quite large. Two of the team members where I am currently working keep ranting and raving about how "If we were using NHibernate...", "NHibernate would be able to do this easier..." and so on.

Nearing the end of one of our projects, I am finding myself having some free time, yet nothing to fill that time with. What a great opportunity to familiarize myself with a new tool, even possibly prepare myself to implement it in the coming project.

After taking a first stab at the tool, I can say that the concepts are pretty simple to grasp. Once you finally get it working, you can see a lot of the benefits that it can bring to a project. Speed and time are definitely saved in having to write schema scripts and stored procedures. The only drawback that I can see with the tool, is the learning curve of setting up the XML mapping documents and configuring the tool correctly.

It was probably two days that I had been looking at NHibernate and getting things initally set up wasn't too difficult. As soon as I attempted to create a DB schema and insert one-to-many relationships, all of my motivation flew out the window. I ran into the issue of my child elements not being linked to my parent elements in the database. The parent ids were not getting stored and as a result they were stored as null. I had 3 other developers, all who of which had one-to-many relationships working with the tool in the past, look at what I had set up. We were all mind boggled. It was only then that one of the developers said, "Get rid of all the table="something" and column="something" so we can simplify the issue. After doing so, the ids for the parent-child relationships were being set. Further investigation lead to the discovery that one of the table names didn't match what was defined. This lead to the null entry in the child table for the parent id. Now the problem is solved, but the issue remains that although the tool is very powerful and makes your life easier, it can also just as quickly drain you will to live. Be careful with your spelling, and remember to bring a problem to its simplest form.

To Mock-You or to Moq?

Recently I have been introduced to a mocking framework build specifically for .net 3.5 and C# 3.0. This framework is called Moq. More information, downloads and documentation can be found @ http://code.google.com/p/moq/

As a brief introduction, Moq is simple. That is all their is to it. The complexity of record and replay has been completely removed from the framework, well actually it was never introduced. We all know how annoying it was to learn the syntax of record and replay, and even once you understood it, really you still didn't.

Moq takes advantage of LINQ and Lambda expressions to do all the work. Here is an example of a simple person presenter test:



Moq makes learning and using mocking simple.