VB.10: Yield to the pressure and give us enumerators!

Unless you have been under a rock for sometime, you would have heard about the amazingly powerful CCR (Concurrent Coordination Runtime) from the robotics group in Microsoft.

In my case in particular, I could see the CCR making significant performance improvements to my current work project.  But there is a catch.  VB.net (3.5 SP1) does not support the 'Yield' keyword that C# has had since 2.0.

CCR uses some nifty manipulation of the enumerator pattern to make asynchronous code appear to be sequential.  An essential part of this ability comes from the usage of the Yield keyword.  The C# compiler reads the enumerator class and converts it into a State machine.  Long story short - it is quite a clever approach.

VB.net Team, please hear our cry.... Add the Yield command please!

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=381572

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.

SQL 2008 Express Management Tools Released

Microsoft has released the new management tools for MS SQL 2008 Express
http://www.microsoft.com/express/sql/download/

Where was this earlier? I installed SQL 2008 on my new home server last week only to find that there was no compatible management tool.

Oh well.... Can i be bothered uninstalling SQL 2005? Will they play well together?

Maybe....

MVC development

Well, I've finished the website in record time.  Developing on the new ASP.net MVC platform has been a treat really.  I really love the cleaner urls.

Could you go back to old url's like this: http://www.domainname.com/products/product.aspx?productID=12

when compared to MVC:

http://www.domainname.com/products/product/12

Plus the newer MVC pages are much more lean and clean.  Not to totally dis webforms as they really opened up web development to me from my winforms background.

BUT there was a hiccup - deployment wasn't exactly what I expected. IIS 6.0 wasn't too frilled with my extention-less urls at all.

Thankfully a quick Google search provided a timely and easy solution.

Now... if the DNS changes would just hurry up already!

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.