How Do I Simultaneously Navigate Multiple Web Browsers?

With some JavaScript and Socket.IO!

However, before getting into that, here's a little background on why I needed to do this (feel free to scroll down if you want to jump to the code). Working as a developer, the majority of your code will be aimed at being deployed in production. By production, I mean an environment where it will be used to provide value to the organization employing you, be this a customer facing web application or a test harness that's used as part of the build process. When you are developing for a production environment, it makes sense to stay within the confines of the current tech stack that is being employed, unless it really makes sense to introduce a new element. For example, if your organization develops their web applications using only ASP.NET, it wouldn't make sense for one developer to start developing a couple new pages in PHP. Sticking to a tech stack improves maintainability tremendously, but it can also limit our ability to see beyond that technology stack. This is why I savor the opportunities to code something that won't go to production and won't need to be maintained by anyone. This gives me the freedom to choose whatever technologies I feel I can be most productive using to solve the problem at hand. It's great not to be confined to your production stack and have the opportunity to step outside of the box and try something new.

One of these opportunities presented itself when I ran into an issue where it appeared either sessions were getting mixed up or the wrong value was being used for the Set-Cookie HTTP header entry. From examining the webserver's logs and the database's audit log, it was clear that the affected parties' requests reached the webserver at exactly the same instance. This meant, that in order to attempt to reproduce this issue, I needed a way to trigger multiple browsers to navigate to the same URL at exactly the same time in order to increase the likelihood of causing an occurrence as this issue did not raise itself every time two or more requests were received simultaneously. This was the moment I had been waiting for, the moment to try something new!

I decided to use node.js as I felt that I would be able to get something up and running with minimal friction. The first solution I considered was where the browsers would repeatedly poll the server and ask if they should navigate or not. When the server said yes, each of the browsers would then navigate to the website I wanted to test. In my mind's eye, the implementation of this would be very easy for both the client and server, but something didn’t feel right about it. I ended up dismissing this approach as the accuracy of the synchronized navigation would rely solely on the shortness of the poll duration. I felt that the command to navigate should be sent from the server to all the browsers in the form of a broadcast. This led me to web sockets and ultimately Socket.IO.

The solution that I created has an index page and an admin page. When browsers load the index page, a connection is established with the web server and a message is broadcasted to the other connected browsers that one more has connected. The admin page allows messages to be sent to the connected clients and to command them to navigate to a url.

Server side

app.js:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

(function () { 'use strict'; var http = require("http"); var express = require("express"); var app = express(); var router = express.Router(); app.use(express.static(__dirname + '/public')); router.use(function (req, res) { res.status(404).send("Did you get lost?"); }); router.use(function (err, req, res, next) { console.log("ERROR:"); console.dir(err); if (req.xhr) { res.set('Content-Type','application/json'); res.status(500).send({ message: "Oops, something went wrong." }); } else { res.status(500).send("Oops, something went wrong."); } }); app.use('/', router); var port = process.env.PORT || 3000; var server = http.createServer(app); server.listen(port); require('./sockets.js')(server); console.log("Listening on port %d", port); }());

The majority of this is plumping for Express.js. The most significant part is line 34 as this is where the call to configure Socket.IO is being made. I've taken a liking to my modules returning a function when they need to perform some initialization upon import. Once you invoke the initialization function, this can then return the API for the module. This construct mirrors the behavior of a constructor by helping to ensure that the module is in a valid state before you start to use it. This can be seen at line 34 where I am invoking the imported sockets.js module and passing in the server variable. In this case, there is no API returned as once I've setup Socket.IO, I do not need to interact with it again.

sockets.js

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

(function () { 'use strict'; var socketio = require("socket.io"); module.exports = function (server) { var io = socketio.listen(server); io.on('connection', function (socket) { socket.on('join', function (data) { var address = socket.handshake.address; console.log("Joined: " + address); socket.emit('joined', { message: "You are connected!" }); }); socket.on('send message', function (data) { console.log("Message: " + data.message); io.emit('client message', { message: data.message }); }); socket.on('navigate', function (data) { console.log("Navigate: " + data.url); io.emit('navigate browser', { url: data.url }); }); }); }; }());

Socket.IO revolves around emitting events and responding to them. Line 9 is an example of how you would setup a callback to respond to a "connection" event that is received by the server though the use of the on function. Responding to the "connection" event is the standard pattern for setting up the behavior for when a new connection is established. In lines 11 through 30, I am creating three listeners that will react to the connected socket emitting "join", "send message" and "navigate" events. The "send message" and "navigate" listeners both emit events of their own. As there are broadcasted on the io channel, they will be sent to all the other connected sockets. However, the "join" listener is only emitting the "joined" event on the connected socket. When you emit an event, you have the option to send data with it and this can be seen as the second parameter of the emit function.

Client side

index.js

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

(function () { 'use strict'; var messages = document.getElementById('messages'); var addMessage = function (message) { messages.innerHTML = messages.innerHTML + message + '<br />'; }; var socket = io.connect(location.host); socket.on('navigate browser', function (data) { location.href = data.url; }); socket.on('client message', function (data) { addMessage(data.message); }); socket.on('joined', function (data) { addMessage(data.message); }); socket.emit('join'); }());

admin.js

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

(function () { 'use strict'; var socket = io.connect(location.host); var message = document.getElementById('message'); document.getElementById('message-button').addEventListener('click', function () { socket.emit('send message', { message: message.value }); }); document.getElementById('navigate-button').addEventListener('click', function () { var url = document.getElementById('url').value; socket.emit('navigate', { url: url }); }); }());

With Socket.IO, the client side of the wire follows a very similar pattern as on the server side. After connecting to the server you are returned a socket upon which you can emit events or listen for events. Like on the server, these are done using functions called on and emit. For an example of listening for an event, look at line 13 in index.js and for an example of emitting a client side event, look at line 9 in admin.js. The entire solution can be found on GitHub.

I realize that I could have stuck with the .NET stack and used ASP.NET SignalR to achieve the same results, but I feel that trying something new in a different stack can bring new insights that can help to make you a better developer. Each stack has its good points and its bad, however, if you only stick with the same stack, you will only ever experience the same pluses and the same minuses. By trying different programming languages, web-frameworks, databases, and so on, you can expand your horizons to new and different ways of doing something. You may even find a new solution for a pain-point that's been nagging you since you can’t remember when. I plan to step outside of the box whenever the opportunity presents itself and try something new. And maybe you should too!

Roman Numeral Converter - Functional Programming Style

After watching Venkat Subramanian’s NDC session on Transforming your C# code to functional style I had the urge to try out some functional programming in C# of my own. I decided to re-tackle the Roman Numeral Converter problem which I had previously solved using a strategy pattern design.

My previous solution broke the converter problem down into a number of smaller converters which were each responsible for converting a numeric unit (ones, tens, hundreds and thousands) of the decimal value to its Roman numeral equivalent. I used strategies to represent each of these converters that could be enumerated through to complete the conversion process. You can find more details about my strategy pattern implementation in my blog post here.

Functional programming focuses on treating functions as variables which can be passed about as variables or added into collections that can be enumerated. This shift in programming paradigm can result in very powerful and interesting designs.

From watching Venkat’s session I knew that instead of having a number of strategies as part of my conversion process, I could have a number of algorithmic functions which when combined would perform the conversion process. These algorithms would be functions that could reside in an enumerable type that could be enumerated over to ensure each of the algorithms were applied to the decimal value.

The C# language has a number of types which can be utilized to help facilitate a more functional style of programming. The Action type allows a function which does not have a return type to be assigned to a variable, where a type of Func allows a function that returns a value to be assigned. There are many overloads for each of these types to cater for a range of input and output scenarios. For example, a function which accepts a string but returns an integer could be represented by the type Func<string, int> or Func<T in, T out>.

My functional implementation of the Roman numeral converter uses functions to convert a decimal unit into Roman numerals. These functions accept an integer and return a string so requires the following Func type to represent them:

Func<int, string> 

An implementation of one of the conversion algorithm functions looks like the following:

public static string Ones(int number)
{
 int onesToConvert = number % 10;

 string conversion = string.Empty;

 int i = 1;

 while (i <= onesToConvert)
 {
  if (i == 4)
   conversion = "IV";
  else if (i == 5)
   conversion = "V";
  else if (i == 9)
   conversion = "IX";
  else
   conversion += "I";
  i++;
 }

 return conversion;
} 

I chose to create each of the conversion algorithms as a static method in a static class to help provide an easier API when accessing each of the algorithms:

ConverterAlgorithms.Ones

By using a collection of Func<int, string> types, I was able to create a type which I could add each of my conversion algorithms to and enumerate in order to complete the conversion:

private List<Func<int, string>> _converters;

_converters = new List<Func<int, string>>
{
 ConverterAlgorithms.Thousands,
 ConverterAlgorithms.Hundreds,
 ConverterAlgorithms.Tens,
 ConverterAlgorithms.Ones
};

Once I had an enumerable of Func’s which represented each of the individual conversion algorithms, I enumerated through the converters collection, invoking each function with the number to convert and concatenate the returned conversion result:

string result = string.Empty;

_converters.ForEach(x => result += x(number));

return result;

It’s interesting to compare this approach to my previous solution which used the strategy pattern. The functional implementation feels a little more lightweight and free of ceremony as the strategy pattern required a different type to be created for each conversion strategy, each of which implemented an IConverter interface. The functional approach required none of this with the only constraint being the method signature of each of the conversion algorithms.

A question I debated was when is it preferable to use each approach? Referring to C# 5.0 in a Nutshell, it has some good general advice when the functional (or delegate) approach is more suitable:

1. If the interface only defines a single method.
2. Multicast capability is needed.
3. The subscriber needs to implement the interface multiple times.

In the case of my strategy pattern implementation, points 1 and 3 are applicable. The IConverter interface only included a single method: string Convert(int number) and the IConverter interface needed to be implement multiple times as it was implemented in each of the conversion strategies.

You can find the complete source code, including unit tests, of my functional implementation of the Roman numeral converter here.

Watching Venkat’s NDC session and this brief dabble has peaked my interested in functional programming in general. After listening to a .NET Rocks podcast on the functional programming language Elixir, I could not resist starting to learning this and see what functional goodness I can pick up in 2015.

Sharpening the JavaScript Saw by Building a Promise API

I’ve been working with JavaScript a lot lately and wanted to set myself a small challenge where I would aim to build something small, but meaningful within 60 minutes. One thing that I had wondered about how they actually worked was JavaScript promises. I’ve used them with Angular.js and node.js and thought that building my own basic implementation of a promise would be a suitable challenge. With the task decided, I felt that I needed to put together a few constraints that would drive my implementation and give me a set of criteria for the challenge. These I derived from my experience with using promises and what I had read about them. Here are the constraints that I decided on:

-    The promise can only be resolved once--be this keeping or breaking it
-    An optional callback for failure can be supplied with a success callback
-    Multiple callbacks can be supplied and they will be executed in the same order when resolving the promise

With everything laid out, I started my timer and began coding. It didn’t take long to get something up and running that allowed a single set of success and failure callbacks to be queued but the requirement to be able to supply multiple callbacks was a bit more of a challenge. It took a little bit of a design change and some refactoring before I ended up with a solution that I was happy with. This is what I came up with:

(function (promiseApi) {

    promiseApi.Promise = function () {
        
        var isResolved = false;
        var successCallbacks = [];
        var failureCallbacks = [];
        
        var keep = function (data) {
            
            resolve(successCallbacks, data);
        };
        
        var abandon = function (error) { // "break" is a keyword unfortunately
            
            resolve(failureCallbacks, error);
        };
        
        var resolve = function (queue, state) {
            
            if (!isResolved) {
                isResolved = true;
                
                queue.forEach(function (callback) {
                    
                    state = callback(state);
                });
                
                successCallbacks = [];
                failureCallbacks = [];
            }
        };
        
        var when = function (success, failure) {
            
            if (success !== undefined) {
                successCallbacks.push(success);
            }
            
            if (failure !== undefined) {
                failureCallbacks.push(failure);
            }
            
            return Object.freeze({ when : when });
        };

        return Object.freeze({
            keep: keep,
            abandon: abandon,
            promise: Object.freeze({ when: when })
        });
    };

}(module.exports));

Here are some notes about my solution:

-    I decided to include an “isResolved” Boolean even though I am emptying the arrays as a guard against the promise being resolved again before all the callbacks in the appropriate queue have been invoked. This ensures that any additional calls to resolve the promise will result in no further action.
-    The arrays are being re-initialized as a housekeeping measure to release any resources that they are consuming. As a promise can only be resolved once, it doesn’t make sense to hold on to any of the callbacks in its queues. Originally, I was setting the length of the array to 0, but I learned that this actually blocks the garbage collector until the items in the array are overwritten by new items. In normal use of a promise, you wouldn't add additional success and failure callbacks after the promise had been resolved, so the original callbacks would remain in memory.
-    The use of the “setTimeout” function with a timeout of 0 is to ensure that the callbacks are invoked immediately. However, as this is a node.js project it probably would be more efficient to use process.nextTick().
-    To prevent the behavior of a promise being changed, I have used Object.freeze() to make it immutable.
-    In an attempt to keep things clean, I used the revealing module pattern.

This is a very basic implementation of a promise API. I’m sure that there is much that doesn’t adhere to the promise specification, but as I mentioned above, this was just a challenge that I set myself to exercise my JavaScript muscles. I wouldn’t recommend that anyone use this code in production even though—technically—it does work. For one, there’s no error handling and if anything were to go wrong when calling a callback, it would continue to bubble up the call stack. The start of a solution would be to wrap the callback’s invocation in a try-catch block, but what would the appropriate course of action be once an exception has been caught? I think I’d have to refer to the specification for guidance on that. Below is a simple example of how to use the promise API:

carService.js:

(function (carService) {
    
    var promiseApi = require('./promise.js');
    
    carService.get = function (id) {
        
        var promise = new promiseApi.Promise();        

        setTimeout(function () {
            
            var data =  {
                id: id,
                model: 'Ford Mustang ' + id,
                year: 2014
            };

            promise.keep(data);
            //promise.abandon({ message: "Something went wrong" });
        }, 1000);
        
        return promise.promise;
    };

}(module.exports));

app.js:

(function () {

    var carService = require('./fakeCarService.js');

    carService.get(1)
    .when(function (data) {

        console.log(data.model);

        return data.model;
    }, function (error) {

        console.log("Error: " + error.message);

        return error;
    })
    .when(function (data) {

        console.log("Second CB: " + data);

        return data;
    })
    .when(function (data) {

        console.log("Third CB: " + data);
    }, function (error) {

        console.log("Second Error CB: " + error.message);
    });

}()); 

As a challenge to help me practice JavaScript, this was a good problem to solve. The complete node.js project can be found here.

Useful Visual Studio shortcuts, tips and tricks from the trenches

Visual Studio is a beast of an IDE with plenty of gems of functionality hidden away possibly never to be found in your day-to-day work. Below are some handy shortcuts which I use and tips / tricks I have picked up along the way to help get the most out of using Visual Studio.

Please note, not all of these will work in versions of Visual Studio prior to Visual Studio 2013.

Keyboard Shortcuts:
Ctrl + [ + S - Highlights the file you are viewing in the Solution Explorer. 
Alternatively type “track” into the Quick launch (Ctrl + Q) bar and you can enable a setting that will automatically track the file you are viewing in the Solution Explorer.

Ctrl + K + C – Comments the selected text.

Ctrl + K + U – Un-comments the selected text.

Alt + [UP] – Moves the highlighted text up a line (great for refactoring and moving code around).

Alt + [DOWN] – Moves the highlighted text down a line.

Alt + [LEFT] – Displays the Intellisense selector.

Shift + Delete – Deletes the current line (handy when clearing out unnecessary white space).

Ctrl + Alt + L – Moves the focus to the Solution Explorer (Allows you to navigate around the solution explorer without having to use the mouse).

Ctrl + G – Go to line number.

(Ctrl + R) + (Ctrl + R) or F2 – Rename (Very useful when renaming methods / variables).

Ctrl R, M – Extract Method.

(Cursor within Implemented Interface declaration) Ctrl + . – Displays the implement interface context menu.

(Cursor within out of scope item due to missing using statement) Ctrl + .  – Displays the using statement import / generate class context menu.

(Cursor is beside a brace { or }) Ctrl + ] – Toggles between opening and closing braces (Use in conjunction with the shift key to highlight everything within a particular braced scope.

(Cursor is in the middle of a line) Ctrl + Enter – New line above the current line.

(Cursor is in the middle of a line) Ctrl + Shift + Enter – New line below the current line.

Ctrl + , - Navigate to a file. Type the filename in and Visual Studio will locate file names which match what you are typing. Easy way to locate files in a project. You can use the pascal casing trick demonstrated in Intellisense – Pascal Casing below.

Alt + F12 – Peek. The equivalent of Go to Definition (F12) but within your current tab.
(Whilst in peek window) Ctrl Alt – and Ctrl Alt + - Cycle through peek tabs.

Display all thrown exceptions (handy for locating swallowed exceptions):
By default, Visual Studio will only prompt when an exception is “User-unhandled”. Sometimes it is necessary to be alerted whenever an exception is thrown regardless if it’s being handled or not (just in case it’s being swallowed or you are interested in the specific location that the exception is being thrown from).

The Exceptions (Debug > Exceptions… or Ctrl + D, E) dialog can help here.

Specify which exceptions you want to be notified of whenever an exception is thrown by checking the corresponding “Thrown” check box and you are ready to go.

Scroll bar – Map Mode:
If you have a wide screen monitor and want to maximize the use of that white space real estate usually located in the centre of the screen, try enabling map mode for the vertical scroll bar.
Right click on the vertical scroll bar and select “Scroll Bar Options…”. In the Behaviors section, select the “Use map mode for vertical scroll bar” radio button and configure if you would like a preview tool tip plus the width of source overview.

When configured you will have a nice source map with optional preview tool tip at your disposal.

Intellisense – Pascal Casing:
You do not need to type the full name for Intellisense to find the item you are after. For example, for Console.WriteLine, Console.WL is all you need.

Special thanks go out to Tarek Madkour for his Tech Ed talk on Visual Studio IDE Tips and Tricks as a number of these came from there.

Pluralsight - Building End-to-End Multi-Client Service Oriented Applications

It took me a long time to decide to watch Pluralsight's Building End-to-End Multi-Client Service Oriented Applications course by Miguel Castro. At 11 hours and 43 minutes in length, it was going to be no meager undertaking and compared to all the other courses I had taken from the Pluralsight library, this one was going to be by far the longest. Once I start something, it's very important to me to finish it so I wanted to be sure that this was not going to end up being a struggle just to reach the finish line. I had watched a couple of sessions that Miguel had given at various conferences and found the content to be both well thought out and well presented. I assumed that this would be the case for this course, which aided my decision. I was also looking for a way to further develop my understanding of SOA and given the depth of this course, it certainly looked like it would be able to help me achieve that.

The course starts with a demonstration of the application you will be creating, followed by an introduction to SOA and then an explanation of the application's architecture. I like how Miguel did not waste any time here and with less than an hour on the clock, he was diving into writing code. He starts with defining the entities (both for the client and server sides of the wire) and then moves on to using Entity Framework to craft the data access layer. Following this he tackles the business layer, where you learn about how he creates services and "business engines". The next two modules are focused on service hosting and client access, with the final part of the course spent creating both an ASP.NET MVC website and a WPF desktop application. I did not watch the modules on developing the WPF application as my primary focus for this course was related to web application development.

The exercise files were a highlight of the course and it is clear that a lot of time was spent on them. I really like how Miguel has created a "starter" and "complete" version for each of the modules. I would start with the starter version and code along with the course, only using the complete version as a reference. The most useful part for me was that once a module was complete, I could begin the next one with the next starter version. By using a "clean slate" that is in perfect condition at the start of each module, I didn't encounter any "what went wrong?" moments that you normally experience when you are using your own copy throughout a course. Another benefit of this was that it allowed Miguel to cram even more value into the course by only having to teach the pattern and not having to implement it over and over. Once he had demonstrated it, I had the opportunity to either complete the implementation with the starter version, refer to the complete version to check my understanding, or move onto the next module and use that module's starter version. The ability to be able to choose what and how much I wanted to code was really beneficial in helping me stay committed to the course.

Many important concepts are introduced throughout the course, but the one that resonated the most with me was how a well-designed application can re-use the same pattern in multiple places. Miguel’s example of this was his use of abstract factories serve to the data repositories in the data layer and the business engines in the business layer. Using the same pattern increases readability by adding a common structure to the application that anyone maintaining the code base can rely on. Once the pattern is understood, you will now have an understanding of what is happening wherever the pattern is used. This is one of the major benefits of using patterns.

Another highlight for me was the MVVM pattern with Knockout.js. Having already used Angular.js for multiple applications, I was familiar with the SPA concept, however, I had very little experience with the MVVM pattern and Knockout.js. By the end of the website modules, I was able to go back to a feature that had been written using only jQuery and re-write it to use Knockout.js with a completely segregated view model, view and model. It was very rewarding to see an immediate return from watching this course.

In total, I probably spent somewhere in the region of 25 hours watching and coding along with this course. I am already planning to watch the course again where I aim to build a bare bones version which I can use as a starter template for future applications. If you are looking to learn about how to build real world applications from the ground up using Service Oriented Architecture, then this Pluralsight course is a must watch and will be more than worth the investment of your time!

Oh and I’m looking forward to part two of this course! Although, I did notice that any mention of this has been removed in the Angular edition, unfortunately.

My First Open Source Contribution!

I have been wanting to get involved in an Open Source project for awhile now but have always felt it was no small undertaking and if I am honest, a little intimidating. Either you have to build a project from scratch, get involved in a project at its inception or get involved in a project that is already in development. Each of these options requires a lot of effort with the later probably being the most popular option.

Whilst working on a pet project where I was attempting to build dynamic reports / dashboards I was using the Jquery.Sparklines charting framework for my inline charting and I noticed that the bullet chart was not working as I was expecting it too. The line and bar charts allowed me to specify a min and max value at initialization to define the value range that the chart would be displaying. This would set the scale for the chart so it made visually comparing charts possible as they were all render using the same scale. Strangely, the min and max values for the bullet chart were being ignored with max value for each chart being determined by the max value from the values supplied to be displayed by the chart. This resulted in each bullet chart having a different scale and made visually comparing bullet charts impossible.

Inspecting the Jquery.Sparkline source code revealed that it was not checking if a min and max value had been specified. Instead, it was determining the min and max range for the chart from the values supplied to be displayed by the chart.

min = Math.min.apply(Math, values);           
max = Math.max.apply(Math, values);

Looking at how some of the other charts handled this, I saw the pattern in use was a ternary statement which checks if a min or max value has been specified, if so use this, otherwise determine these values from the data values supplied. My update using this pattern looks like this:

min = options.get('chartRangeMin') === undefined  

  ? Math.min.apply(Math, values) 

  : options.get('chartRangeMin');
max = options.get('chartRangeMax') === undefined 

  ? Math.max.apply(Math, values) 

  : options.get('chartRangeMax');

Now the bullet charts are rendered with the same scale as they all have the same max value specified and a visual comparison is possible.

In the context of my report, the bullet charts now give a much better visual report of how students are performing against one another.

Creating a Pull Request in GitHub was surprisingly easy, especially now that a forked branch of a project can be used in the pull request as you no longer require any privileges on the project that you want to contribute to. It's made the whole process pretty much ceremony and friction free. For details on how to make a Pull Request from a forked branch check out this tutorial.

You can find my pull request here.

It's a very small update and contribution but it's a start. There is additional logic being applied to the min value which would need further consideration and possibly lead to a modification to my pull request but it's the start of a conversation with the project owners at the very least.

I have learnt that it is important to find an Open Source project that you have an interest in when searching for projects to make a contribution to. It's even better if you have a vested interest because you are using the project or are looking to use the project. Previously when looking for projects to contribute to I was looking at shiny new projects instead of looking at projects which I was using.

Contributing to an Open Source project can also help you improve your coding skills as it gets you reading other people code. I picked up a number of patterns and coding techniques whilst perusing the Jquery.Sparklines project that are worth further consideration and study.

If you feel getting involved in an Open Source project is a little intimidating you are not alone there. Find a project that you are interested in (and preferably use) and start by making a small contribution (bug fix, test code, documentation). As they say, "from small beginnings come great things".

The Common Service Locator

If you are requesting services directly from your IoC container, this should be a code smell that you should consider using the Common Service Locator instead for this. By using an IoC container, you have decoupled the execution of a task from the implementation, but by requesting these dependencies directly from the container, you are now coupling yourself to the container. If you decide that you want to change the container that you are using, you will have to update both the libraries and all the locations where you are directly requesting from the container. This is an additional headache that you can avoid by using the Common Service Locator.

The CSL acts a wrapper around your choice of IoC container and provides a common mechanism from which you can can request services from it. If you are to change the container that you are using, the way you request services would not be affected; all you will need to do is set the locator provider to use your new container and everything else can remain the same. Here's a C# example using StructureMap:

1 2 3 4 5 6 7 8 9 10 11 12

//Configure the container like before var container = new StructureMap.Container(x => { x.For<IDataRepository<Car>>().Use<CarRepository>(); }); ServiceLocator.SetLocatorProvider(() => new CommonServiceLocator.StructureMapAdapter.Unofficial.StructureMapServiceLocator(container)); //Get a service: //var repo = StructureMap.ObjectFactory.GetInstance<IDataRepository<Car>>(); var repo = ServiceLocator.Current.GetInstance<IDataRepository<Car>>();

Where as previously the service would have been requested directly from the container (line 11), it is now being requested from the CSL. If you want to replace using StructureMap with something else, you would only have to makes changes to where you set the locator provider (line 8). In the example above, I am using the StructureMapAdapter that I installed via Nuget, but a quick Google shows that there are CSL adapters for all the major IoC containers.

Decoupling yourself from your IoC container is the next logical step in writing decoupled code and the Common Service Locator is a very easy way to achieve this.