loose coupling vs tight coupling?

Jul 7, 2011 at 2:51 PM

I can see you have a number of assemblies, for example Wolfpack.Core.Interfaces.Castle, which appear to break out individual interfaces so they can be swapped with alternative implementations.  However, on the otherhand Wolfpack.Core has direct dependencies on various libraries, such as Castle.Core and Magnum. I am wondering which way your direction is going?  The assemblies Wolfpack.Core.Interfaces.Magnum and Wolfpack.Core.Interfaces.Castle are really small and could be merged with Wolfpack.Core. Or the direct uses of Magnum and Castle in the Core library should migrated into separate assemblies.

My personal preference would to decouple the use of NServiceBus, Geckoboard, Growl etc from the main core assemblies.  If I am not using these components, it would be nice not having to deploy the dependent assemblies.  However, all of the assemblies together are relatively small (less than 10MB).

Jul 7, 2011 at 3:09 PM

Hi - It was originally all in into two assemblies - core & core.interfaces.

However when I tried to write a contrib module as a test (prior to NuGet) it was apparent that if you wanted to develop a HealthCheck you would need to cart everything along - even Magnum when it wasn't required to write a custom HealthCheck.

The interfaces.magnum split was required to allow you to grab a minimum codebase to write a HealthCheck.

Interfaces.Magnum & Castle are extensions to allow you to write Publishers, only publishers have dependencies on Castle (interception) and Magnum (message consumer) - one of the ideas was to merge these into Interfaces.Publisher as it would make more sense (functional grouping rather than technology) - however the advent of NuGet allows you to package in functional groupings so have left it as is - hence Wolfpack.HealthCheck & Publisher packages. To be honest to only reason for Interface.Castle is that I've been a bit lazy and exposed a castle member in an interface class - if that was wrapped it could disappear - the idea was the Container was agnostic and you could provide your own....interception screwed that up a bit but it is fixable.

Re further splitting - I've been toying with splitting out the the bits you mention - create new NuGet packages for bus, geckoboard etc. (I'm working on a GUI that will allow you to pull down wolfpack packages directly into the app so this might be the way to go).

Cheers for the feedback - keep it coming!