Kian Ryan (.NET, Android, Geekery)

This is part rant, part discussion…

In this modern world, developing database driven applications has become pretty damn straightforward, even for us .NET coders. Start a project, grab a ORM framework of choice (Subsonic, Entity Framework, Linq 2 SQL), define a database, create your tables, generate your classes and POW! Job done.

Which is awesome. Apart from the fact that your class behaviour is now tightly defined to your database behaviour (by default, I appreciate you can change this). Which means in turn, you really should be taking great care in defining your databases, since the closer this maps your domain model, the easier your job becomes.

So why on earth leave your columns set to NULL unless you actually intend to allow NULL values? I appreciate that SQL Server allows a column as null by default, but it has so many implications if you’re not intending it it’s untrue. Lets take the following examples:

int? Age { get; set; }

if (Age > 0)
{
    Console.Writeline("This is awesome folks!");
}

int Age { get; set; }

if (Age > 0)
{
    Console.Writeline("This is awesome folks!");
}

Clearly the two are not equivalent. The first wont even compile, since the compiler has enough sense to recognise that int? could be null and therefore the expression int? > int is not valid.

It could be argued that Age may indeed be nullable, nullable indicating a genuine lack of this piece of knowledge. If this is the case, then we need to take that into account.

int? Age { get; set; }</p>

<p>if (Age == null)
    Console.Writeline(&quot;We don't have an age for this person...&quot;);
else if (Age.value &gt; 0)
    Console.Writeline(&quot;This is awesome folks!&quot;);

In this case we have a potential for three different things to be happening, all of which need to be taken into account. Each one is a semantically important case which requires understanding and testing.

But often a field being left nullable is just a sign of laziness on the part of the database being developed. The giveaway is when the following code is spotted:

int? Age { get; set; }</p>

<p>if ((Age ?? 0) &gt; 0)
{
    Console.Writeline(&quot;This is awesome folks!&quot;);
}

The ?? operator is an expressive operator used to define a default behaviour, not to correct a mistake made elsewhere by the developer. It would seem common sense to go back and change the model so that the code reflects the first example, but more often than not I see developers opting for option above.

Please use NULL wisely.

I could kick myself for this one… The credit goes to a co-worker, who spotted this one straight off the bat.

I’ve got two projects at the moment which consist of a DAL, a website and an admin site. Pretty straightforward projects, with large quantities of content stored in the website folder_. When building the project on our CC.NET build server, through an msbuild exec, the website would appear to compile pretty quickly, and then sit around for forever before finishing.

The guilty party is the precompiled site folder. When the site is being compiled, all the assets from the original site are being copied, including the several gig of content, which causes the process to hang for a minute or two while the files are copied. Move the files out from the website and hey presto, back to fifteen second compile times.

I’ve been using ASP.NET MVC for a couple of projects now, and so far my assessment is lukewarm. I like it in that it lets me play with raw data and is increadibly powerful, extensible and testable. It does take quite a while to spin things up though, and you can end up in a headache of chase the forms. It’s quite likely I’ve not quite got the hang of it yet, but that’s fine.

One tool that has proved invaluable to my understanding of forms, FormCollections and the noise going backwards and forwards between my app and the browser is Fiddler 2. It’s a proxy server with a UI over the top that lets you see the requests and responses that are sent between your web browser and server. It’s great to understand the shape of the data your sending to the formCollection, whether various fields are sending the right name, checking that JSON data as it’s coming back etc. In no respect should it replace testing, but it makes understanding the flow significantly easier.