WCF and IIS 6.0 Hosting Issue

I've developed a WCF Service which I have tested extensively in the Visual Studio environment.  I have had it successfully hosted on Vista and also Windows XP.

Today when I attempted to install the Service on my windows Server 2003 machine, it refused to display the .svc file.  It would only return a 404 error.

After much stuffing around I found this resource which described the same problem I was facing. (Always nice to know you are not alone!)

The only method that worked for me was uninstalling and reinstalling IIS.  I then repaired my .NET 3.5 SP1 installation and Vola! A visible svc and wsdl file!

Wow what a waste of an afternoon that was!

Entity Framework Verses LINQ to SQL

I have found myself in a rare opportunity to redesign the Data access layer in a WCF web service application.  Previously we were using a mixture of table adapters and typed data-sets abstracted away behind 'manager' classes.  By defining the manager classes with interfaces and creating mocking version we were able to easily decouple the functionality from the data.  The Data-set representations themselves being the only exception.

I have significant experience using typed data-sets on many projects. And I must say I have become rather sick of writing CRUD operations, sure learning to use new design patterns with them has brought new life.  But really... Do I need to define this stuff over and over again?

I am sure that I am not alone.

I'd heard about LINQ to SQL earlier in the year and had briefly toyed with it.  I'm a big fan of the LINQ concept, but the performance factor has always kept me weary of it as a technology.

Now for my confession.  I'm a virgin O/R mapping developer.  I have never had the excuse to use any database/object mapping tools on any production code as yet.

So being green, I decided to start learning more about the options available.

I think I am a creature of habit and I will keep to the Microsoft technology stack.  So I freely admit that I did not consider any other contenders.

"To use Entity Framework or Not to use Entity Framework"

I took the plunge and stripped out my table adapters from the DAL.  And in my eagerness inserted a new bright and shiny copy of the Entity Framework from .Net 3.5 SP1.  Being the later (I assumed greater) of the two options I chose it over LINQ to SQL.  And all was right with the world.

That night thoughts came unbidden...

How does the context know what to update?

Are two context instances independent of each other?

How do I make atomic level commits?

Can only the original context instance update any changes?

So this morning I was determined to nail this thing out.  Firstly I started making sure I understood how the entity framework behaves (and cracks it).  It is amazing how different using a O/R mapper is from simple Typed Data-sets.  But the more I played with the entities the more doubts crept in.

Previously my Manager classes would happily accept my word on the fact that a foreign key was correct.  The Entity Framework isn't so polite.  After playing around I stumbled upon a method of entity association which satisfied it.  Now I was really starting to worry, I had previously assumed that I could keep my changes limited to within the manager classes with the rest of the application none the wiser to the difference.  But Entity Framework was either demanding I Load the related table in order to associate the entity, or I was going to start leaking outside of my manager class.

I really really didn't want to leave the manager classes. 

While testing out the Entity Framework, I decided it would be worth while comparing it to raw data-sets / table adapters and also the LINQ to SQL alternative.  I set up a simple test of adding a new entry into the account table with a valid foreign key in the user table. 

The results were something of a surprise:

Entity Framework	8,700 milliseconds
LINQ to SQL	3,100 milliseconds
Data-sets	2,000 milliseconds

With only 500 repetitions it was quite clear that the Entity Framework is significantly slower.  What I didn't expect to see was how fast LINQ to SQL is!

And the real clincher for me was that I can manually set the foreign key with LINQ to SQL.  Also if speed becomes a critical we can down-grade to Data-Sets again.

Work progresses

Just when you thought you were meant to be testing... you find yourself developing more changes to your code!  Ever find yourself doing this?

This must be the main reason why it is common practice to get someone else to test your code. 

Is this a form of agile programming?

(Hoping to justify my actions here)

Either way; I'm really enjoying the combination of unit testing with mock classes.

I'm not using a standard mocking framework though, I've found the easiest way to remove dependences has been to use the following steps:

1. Define Interfaces: This is probably a very obvious step, but I'm pretty new to unit testing so I haven't had any real need to create any before.
2. Use a Simple Factory: Use a Simple factory class to create concrete instances of the interface.  This allows you to swap the concrete implementation for a mock version.
3. Create a Mock Version: Control of the mock version is supplied by static variables inside it.  Because they are static you can reach in from inside the unit test and determine the mock classes responses.

It is then a simple matter to build unit tests which can ensure 100% code coverage. 

If you were anything like me and were unsure of unit testing.  Don't avoid it because of the overly complex mocking frameworks.  With a little interface magic you can easily create your own mock class implementations.