Back and working

So I’m back and ready to go, with just getting back from my travelling I’m back at work with only two days of my own time….!  Oh well I was looking at taking December off and start fully working in the new year.  Not that I took the first job that came along, far from it.  While on the beaches of Goa I made up a list of what work I will only accept it included working near where I live, work I have done before so as to make it easier to get back in to the working mode, something to do with the Olympics, and a small team on a new project.  And you guessed it this role fits all the criteria so a result 

Laughing

So time to keep my blog up to date and running again……!

 

Using MEF to provide PlugIns

MEF has now been released, a Plug-In Framework, for .Net 4.0

After reading up on CodePlex, I have generated a small application that provides a plug-in framework, see attached below.

http://mef.codeplex.com/wikipage?title=Guide&referringTitle=Overview

MEF.zip (70.88 kb)

I’ve also produced a .NET 3.5 version too:

MEF in 3.5.zip (427.41 kb)

Few MEF links:

Glenn Block

Nicholas Blumhardt

MEF on CodePlex

Channel 9 Silverlight 4 MEF Screencasts

MEF 101

XSD to Objects

I’ve been dealing with REST services within WCF, and one thing that has come to my attention is that the calling service or third party only has access to the REST interface and the XSD’s.

The XSD’s holds all the contract information, therefore if you need to generate a concreteclass you are going to have to translate the XSD to an object. 

I’ve have come across the XSD Object Generator frm Microsoft which appears to do the job.

XSDObjectGen.msi (667.00 kb)

Lifestyles of the Castle Windsor IoC Containers

It’s worth knowing how the Castle Windsor IoC work, by default it uses Singletons, where this will work for the most of the time, there are a lot more options available to you depending on your needs.  These lifestyles that are available in Castle Windsor are:

  • Singleton: components are instantiated once, and shared between all clients
  • Transient: components are created on demand
  • PerWebRequest: components are created once per Http Request
  • Thread: components have a unique instance per thread
  • Pooled: Optimization of transient components that keeps instance in a pool instead of always creating them
  • Custom: allows you to specify a custom lifestyle… you’d have to specify a type that implements the ILifeStyleManager interface

For further information on this take a look at Castle Windsors Lifestyles or  Windsor and component instance lifetimes

Introduction to Dependency Injection

Dependency Injection (DI) is an incredibly useful and easy technique which makes your code a lot easier to test.

I like to use samples to explain Dependency Injection. We’ll use a SqlMetaDataProvider class which needs to provide the meta data coming from a SQL Server database. It retrieves the meta data from the database in a relational structure (a DataSet) and then converts it to an easy to use object model. Obviously, i want to be able to test this class without actually going to the database because that would make the tests slow. So how can we test if the relational data is being converted to the object model without going to the database?

Well, let’s look at what the class does. First of all, it retrieves sql server meta data. Then it converts it to an object model. But retrieving the meta data doesn’t really belong here… it should be functionality that’s offered by another class. So we create a SqlDataRetriever class. All it will do is return meta data in the relational structure. Nothing more. So now, our SqlMetaDataProvider class can simply use the SqlDataRetriever class to retrieve the meta data. So basically, SqlDataRetriever is now a dependency of the SqlMetaDataProvider class because SqlMetaDataProvider is depending on SqlDataRetriever to return the relational meta data.

At this point, our class could look like this:

    public class SqlMetaDataProvider : IMetaDataProvider
    {
        private readonly string _connectionString;
        private readonly SqlDataRetriever _sqlDataRetriever;
 
        public SqlMetaDataProvider(string connectionString)
        {
            _connectionString = connectionString;
            _sqlDataRetriever = new SqlDataRetriever();
        }
 
        public MetaDataStore GetMetaDataStore()
        {
            SqlMetaData sqlMetaData = _sqlDataRetriever.GetMetaData(_connectionString);
 
            return ConvertToMetaDataStore(sqlMetaData);
        }
 
        private MetaDataStore ConvertToMetaDataStore(SqlMetaData sqlMetaData)
        {
            MetaDataStore store = new MetaDataStore();
 
            AddTablesToStore(sqlMetaData.TableInfo, store);
            AddColumnsToTablesInStore(sqlMetaData.ColumnInfo, store);
            CreateRelationshipsBetweenTables(sqlMetaData.RelationshipInfo, store);
 
            return store;
        }
    }

Note: I left out the code for the AddTablesToStore, AddColumnsToTablesInStore and CreateRelationshipsBetweenTables methods because they aren’t relevant to this specific topic.

Now we need to make sure we can replace the instance of SqlDataRetriever during testing with one we can supply ourselves. That test instance could then simply return a DataSet that was created in-memory, thus keeping our tests running fast. Notice how SqlMetaDataProvider has a reference of the type SqlDataRetriever. The type is essentially fixed, which creates a strong dependency on the SqlDataRetriever class. If we were to replace the type of the reference with an interface, it would at least make it easier to use another type for our required dependency, one that simply implements the interface.

So we create the ISqlDataRetriever interface:

    public interface ISqlDataRetriever
    {
        SqlMetaData GetMetaData(string connectionString);
    }

And then we modify the definition of SqlDataRetriever to implement the interface:

    public class SqlDataRetriever : ISqlDataRetriever

Now we need to modify our SqlMetaDataProvider class so it holds a reference to the interface type, instead of the class type:

        private readonly ISqlDataRetriever _sqlDataRetriever;

We still need to find a way to inject our dependency into our SqlMetaDataProvider so we’ll modify the constructor:

        public SqlMetaDataProvider(string connectionString, ISqlDataRetriever sqlDataRetriever)
        {
            _connectionString = connectionString;
            _sqlDataRetriever = sqlDataRetriever;
        }

The only downside to this is that it now takes more work to create an instance of SqlMetaDataProvider… work that clients shouldn’t need to do if they just want to use the default ISqlDataRetriever implementation. If you’re using an Inversion Of Control (IoC) container, you can simply request an instance of SqlMetaDataProvider and the IoC container would also create the necessary dependency for you. Using an IoC container however is outside of the scope for this post, so we won’t do that. In fact, if you know that your production code will always use the SqlDataRetriever implementation, you could also provide a simpler constructor which takes care of that for you:

        public SqlMetaDataProvider(string connectionString)
            : this(connectionString, new SqlDataRetriever()) {}

So you could use the simpler constructor in your production code, and the other one in your test code. Speaking of test code, we still need to write that test which tests the conversion without hitting the database. First, we need to create an implementation of ISqlDataRetriever which allows us to pass a DataSet to it which the ISqlDataRetriever instance should return to its consumer (our SqlMetaDataProvider):

    public class SqlDataProviderStub : ISqlDataRetriever
    {
        private SqlMetaData _sqlMetaData;
 
        public SqlMetaData SqlMetaData
        {
            set { _sqlMetaData = value; }
        }
 
        SqlMetaData ISqlDataRetriever.GetMetaData(string connectionString)
        {
            return _sqlMetaData;
        }
    }

And finally, the test:

        [Test]
        public void GetMetaDataStore_ProvideDataSetWithTwoTablesAndRelationship_MetaDataStoreIsCorrect()
        {
            SqlMetaData sqlMetaData = PrepareMetaDataSetInMemoryWithTestData();
 
            SqlDataProviderStub sqlDataProvider = new SqlDataProviderStub();
            sqlDataProvider.SqlMetaData = sqlMetaData;
 
            // pass null as the connectionString, and pass our SqlDataProviderStub
            IMetaDataProvider metaDataProvider = new SqlMetaDataProvider(null, sqlDataProvider);
 
            MetaDataStore store = metaDataProvider.GetMetaDataStore();
 
            AssertStoreContainsOurTestData(store);
        }
Original article by Davy Brion

Running NUnit from Visual Studio

If you are like me, I like to keep my Visual Studio environment as clean as possible, so if I can get away from adding any addins in to Visual Studio I will always go for that option.

So when it comes to testing I prefer to run with NUnit and run it as n external program.  

To do this just right click on the unit test project -> choosing the properties option -> setecting the Debug tab -> choose “start external program” and enter the NUnit assembly path, in my case this is “C:\Program Files\NUnit 2.5\bin\net-2.0\nunit.exe”, next is to select the command line arguments and point this to your unit test dll,

e.g.  “C:\Program Files\NUnit 2.5\samples\csharp\money\bin\Debug\cs-money.dll” /run

The “run” parameter will automatically run the loaded project

Alternatively you can use a Visual Studio add-in such as TestDriven.Net, this also provides NCoverExplorer to provide you with code coverage.

Building up an MVC application

When you open up MVC out of the box, you get the basic configuration, after a little playing around you soon see areas that require enhancing to, not only make your application more flexable, but also easier to maintain.

Here are a number of additional tasks you can perform that will help with your application.

Which IoC to use?

Don’t worry, if you use the Common Service Locator it provides an adstraction over the IoC

How to validate?

I have already covered this one in a previous post, but I’d still go with xVal

Need to generate Themes?

I think it is so important to start correctly and generating the User Interface should be configurable, the easiest way of doing this is to implement a Theme, and Chris Pietschmann has do this for us, Implement Theme Folders using a Custom ViewEngine

Here is a copy of the source for safe keeping.

ASPNETMVC_Preview5_CustomThemeImplementation.zip (226.05 kb)

Need Ajax to work in MVC

Ajax.BeginForm and PartialViews

Extend the UrlHelper

 

Placing all your assets in one place is not only a good idea, but it also means you can be more flexable if you want to programmically change the theme of your user interface.

 

 

Which can be used like this:

Using Strongtypes and keep away from Strings

It appears so easy with MVC to use String everywhere, just DON’T, generate an extension for the UrlHelper

Now in your view it will look like this

Testing

I’ve been hit before by Microsofts in build Testing within Visual Studio 2008, great to have this feature built in, BUT, and a big but in order to run the tests you need to have Visual Studio install, so if you try and setup a Continuous Integration server you will also be required to install Visual Studio.

So best to go with what works well and that is nUnit, simple and easy, and more importantly loosely coupled

Mocking

With testing comes Mocking, and which framework do you use?  I also always say keep it simple and easy, so I’m going with Moq, short for “Mock-You”, as this is the only Mock Framework that is built around .Net 3.5 and LINQ.

 

 

Mocking

 

In object-oriented programming, mock objectsare simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts.

It is possible to perform integration testing on the Membership Provider, take a look at this blog entry to find out more Integration testing the MembershipProvider

Within the Project we are using Rhino MocksOren Eini is doing a great job with this framework, and I think it’s the only one that seems to be keeping up with the latest features in .NET, other than TypeMock. Plus, it’s totally free to use. It’s also the only one other than TypeMock which does not require you to input strings for method names you’d like to mock, which is cool. It’s compelling to use it but the project is currently maintained by just one person. If Oren decides to drop it, or for any reason stop working on it, the book might turn out outdated quite quickly. Plus, it’s not very widely used, though it seems to be gaining in popularity.

References

Introduction to Mocking with Rhino Mocks

Mocking

Code Samples

 

Configuration for NLog

When I am writing an application it is so important to make sure you record and log information correctly, there are a number of free loggers you can use

I have come to use NLog, by Jaroslaw Kowalski, it’s so easy to use and get up and running, which is what you really need if you are using a logger of any type.

But what is the best practice when using a log in a live environment?

Or more importantly what and how do you configure you configuration file to make sure you are logging all your information?

The way I see it is, capture your logging to the Event Log and a Database for information and tracing.

When it comes to Errors and Fatal logging then, write it to as many places as you can, an Error file, the Event Log, a Database Log, and perhaps a special Exception Database Log, because if something has failed, you’ll want to shout about it, and you want to record it in as many places as possible.

Here is an example of an NLog configuration

NLog.config (2.63 kb)

To setup the database use the following creation creation script

NLogDatabase.sql (1.16 kb)

Make sure within the SQL Database you have a user “nloguser”, with a password of “nlogpassword”, these are both defined in the NLog configuration file, and can be changed if need be.

That is it, all you have to do now is wait for your live application to log some information.

I am sure there are a few other configuration options available and I welcome anyones comments on how to improve this configuration file.