Long time no see!

So it’s been an awfully long time since my last post, and I’m aiming to bring my blog post entries up to speed with my everyday workings and discoveries – So with that I’ll introduce my most recent GitHub project.

This project is aimed at people who’ve been looking at utilising MEF (Managed Extensibility Framework) but are overwhelmed with the amount of refactoring that would be involved to implement it. 

As with any framework, you need to weigh up the pro’s and con’s of each solution, and compare many solutions to find the closest fit to your needs. I think it’s naive for anyone to think that a single framework would cover their project’s every need, but by matching a framework as close to your requirements as possible means that bridging the gaps is a relatively small cost. Especially when you compare to to refactor hell to make your application fit the framework.

One other thing – If you’re starting a new project, this whole post may be irrelevant as you have the freedom to make the design choices when orchestrating your application. Whereas a LOB (Line of business) application that is mature, or a project that has limited staff resources may struggle and so I’m going to introduce a more simplistic choice for anyone that may need it.


I’m sure that you’ve heard many people before use new and trendy development buzz words like SoC (Separation of Concern), or Loosely/Tightly coupled. Though these words have been trending recently, their core concepts have actually been in the minds of developers for decades. 

Q. What is a ‘loosely coupled’ system? Loosely couple first off is not an innuendo though I would welcome a few laughs/suggestions in the comments. I will instead steal the wikipedia definition of the term because I think it’s the clearest explanation without getting into technicalities of development:

In computing and systems design a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components.

Q. How does loose coupling relate to SoC? Hopefully if you’re a programmer you’ll notice that by the definition of loose coupling it almost enforces a Separation of concern. By loosely coupling components when you develop them, you will ensure that components are only dealing with the process they are contained to, and there is no dependency leaking.

Plugins are the best form of SoC

That’s a pretty bold statement I agree, but by physically separating the functionality to a plugin architecture you’re fully separating your business logic with a clear and concise boundary. By having such a clear boundary you’re enabling your application to not worry about the specifics of something like, for example, calculating a shipping cost.

There are of course some draw backs to this, by having such a large boundary you can create some tight dependencies due to the way the .NET framework is composed.

There used to be a namespace of System.AddIn but this is no longer the Microsoft recommended route of implementing plugins – they instead recommend the MEF which can be difficult to bolt on to an existing mature product. 

By utilising a dynamically invoked external assembly (DIEA – Yeah I actually just made that up!) you can implement specific endpoints of OO code with a single line of plugin implementation rather than refactoring your whole class to fit an MEF system.

The drawbacks

Unfortunately this is a difficult thing to get a good example of, but I’ve put up my solution on GitHub that will allow you to get a basic working example. It’s already defeated the main issue with dynamic assemblies, by using CrossDomainMarshalling.


  1. It allows us to instaniate our assembly in a different AppDomain, which means that if they’re any fatal errors in the plugin, it doesn’t bring your whole application down. Just the AppDomain it was loaded into.
  2. It allows us to only hold a lock on the assembly for the lifetime of the secondary AppDomain, rather than the entire lifecycle of the application.
  3. Lastly, it allows plugins to be invoked which reference different versions of 3rd party components (such as NLog)

When you’re done with your plugin, you simply unload the AppDomain you created and all the tear-down is done by .NET to release assembly locks meaning you’re able to update these plugins from within your own application without having to shut down.

Please take a look at the code on GitHub and if you have any feedback or suggestions I’m always eager to learn from others experiences.

Transparent Proxy Service Locator

Quick Note: Just published a quick release of a service locator pattern that uses a transparent proxy to invoke the methods on all implementations of a service without the visibility there may be more than one instance of the service.

It’s probably not the best fit for a full service locator pattern, but using the transparent proxy to intercept the method calls will definitely find a use somewhere! 

See: https://github.com/abbottdev/ProxyServiceLocator


Being tradition I’m going to use my first blog post as a bit of an introduction about myself, what I do, and where I’m going.

So my name’s James, I’m 23 as of writing this blog post. (Yeah, I know I’m a youngster, and I might not know what I’m talking about) However, unlike most my age I’m mature enough to listen and take in advice if I’m wrong about something so please feel free to correct me. The sole purpose for my blog is education, to make being a great software developer an easy and achievable task!

I work in Leeds, a city in England at a software house that produces management and data capture software for the print & media industry. I’m the youngest developer at the company, but (without bigging myself up too much) I’m probably one of the most competent there. (Hey, when it comes to your job confidence is good!) We’ve got a few skilled people here, and we consistently work as a team and produce some of the best products availiable in our industry, breaking bounds and introducing new technologies to make our customers more effective.

That being said, my particular areas that I specialise at my work are:

  1. VB6 development (You may say “Yawn” or you may say “WTF, you’re a little too young for VB6?”) I’ll start by saying you’re right, on both counts. Visual Basic 6 is tedious and slow. But what do you expect for a product that was release when I was 9. I know this stuff, because I learnt Visual Basic 5 (Yep, even older) when I was at Junior School. (Forgive the UK/US school grades, whatever grade you were when you were 10)
  2. VB.NET Development. This ones a lot more up to date. I work with most versions, starting at 2.0, through to 4.5 (the latest one).
  3. WPF Development. This has been a personal passion of mine, ever since I first laid eyes on the technology in use (those lovely looking Windows messenger UIs when they first came out) I’ve wanted to duplicate it.
  4. ASP development. Oh, yeah, did I say I was old skool? I’ve got dozens of projects written using classic ASP, and ASP WebForms. One of my aims over the next few years it to work on more MVC webs, and make use of the benefits of a loosely coupled architecture brings.
  5. SQL Server. Lucky you. I’ll be providing some resources on SQL Server, (specifically Microsoft SQL Server) – and Azure. (I’ll also touch on some No-SQL alternatives)
  6. ORM wrappers. (For those of you who’re unsure, that stands for Object Relational Mapper)
  7. And the rest that I don’t have time to go into more detail today; JavaScript, HTML, CSS, XML/XSL, PLC, Micro framework, Win Mobile, and Windows 8 development.

Anyway, I could ramble all day, but I think that’ll do for my first post.

I hope you enjoy the deliciousness of my blog, as much as I enjoy sharing the information.

Until next time!