Lets face it. Some developers are religiously attached to their beloved languages, frameworks, and libraries.

This becomes a problem when building software with hopes of gaining a developer base. If it is not built on Unity, Castle Windsor, Structure Map or [insert beloved Ioc library here], they refuse to work/use the software.

Evidently others have had this issue and have created a solution, the common service locator.  I ran across while searching for asp.net  mvc and DI (dependency injection) for models. More on DI with models inside controllers in a future post.

How to use

Download the library from codeplex.com/CommonServiceLocator

Its pretty straight forward.  Download the service locator adapter for the Ioc library of your code on the codeplex.com/CommonServiceLocator

choose the adapter for your Ioc library.

Configure your Ioc library in the usual manner. Then pass the container into the adapter.

        private IServiceLocator CreateLocator()
        {
            var container = new UnityContainer();
            container.RegisterType<IUser, User>();
            container.RegisterType<IMembership, Membership>();
            container.RegisterType<IUser, Loser>("loser");

            return new UnityServiceLocatorAdapter(container);
        }

Then tell the service locator which adapter you are using.

        private void SetupService()
        {
            // CreateLocator returns IServiceLocator in the above method.
            ServiceLocator.SetLocatorProvider(() => CreateLocator());
        }

Then use the locator to return the adapter, which will allow you to use a common interface to resolve your dependencies.

        [It, Should("resolve the type to the default")]
        public void ResolveType()
        {
            this.SetupService();
                         // gets the current adapter for the Ioc Library.
            var resolver = ServiceLocator.Current;             

            // resolves the type.
            var result = resolver.GetInstance(typeof(IUser));

            // verify the result is the right type for the contract.
            result.IsInstanceOf(typeof(User));

            // this user should not have a membership.
            var user = (User)result;
            user.Membership.ShouldBeNull();
        }

Some Caveats.

Someone named the base service locator class in a java like manner using Impl.

The assemblies for the Unity Ioc are not strong named assemblies. I had to create a key, sign the assign the assemblies for Unity. You can download the midori-project which has the signed assemblies for Unity under the vendor folder.

Further Usage and Reading

If you would like to check out the spec and see how it might be used, check out the spec in the midori core. This will give you some context.

You can also read more about it on codebetter.com as well as the initial post from Jeremy Miller that spawned someone to write this.

Geek Specs

Ignore the Trekkie reference.  I’ve started to work on the data abstraction layer for Midori, after narrowing down the supported out-of-the-box relational databases.  In no particular order, they are SqlServer, SqlServerCe, MySql, Postgress, and Sqlite. Its being written in .Net 4.0 and hopefully it should port to Mono.

The main abstraction class Midori.Data.SqlAdapter makes use of the System.Data interfaces, like System.Data.IDataReader. Obviously this class will grow as other crud operations are added.  Each RDMS will have a class that will inherit Midori.Data.SqlAdapter, like Midori.Data.Sqlite.SqliteAdapter, which will hold code specific to each database.

There is a Connection class that wraps other connection objects and supplies OnConnect and OnClose events, which should be helpful for closing the connection objects for methods that pass back datareader objects.

Interesting Notes

System.Data.Common.DbConnectionStringBuilder is a handy class for building and inspecting values of a connection string in a hash like way.  Some Ado.Net layers, like System.Data.SqlServerCe, does not implement their own connection string builder. While it is nice to have, its not a necessity, especially when the common dbconnectionstringbuilder will suffice.

Postgres or Npgsql, has some interesting behavior. The following select query has Pascal casing for the names of the columns.

SELECT 'column1' AS Column1, 10 AS Age

However when the DataReader for Postgres returns the names of the columns, they are all lowercase, all the other databases return the column aliases in the same case as specified in SQL.

So in the tests, I had to rewrite the query to use all lowercase column aliases, like so:

SELECT 'column1' AS column1, 10 AS age