Common Interfaces for Tool Families

There are a load of different tool “families” in use in the .NET ecosystem which I’m sure LosTechies readers will take advantage of pretty much every day. IoC containers. Logging infrastructures. URL routing mechanisms. Each of these families operate on broadly similar principals – taking the container example, we know that we need to add types to the container and resolve types which are already in there. For logging, we’d generally have the ability to log to different levels of severity. So you can see that while the implementations and underlying behaviour may be significantly different, there is a layer of abstraction which highlights commonality.

Castle Project has a Castle.Core.Logging.ILogger class which supports the use of a variety of different logging systems within your applications. It is a facade behind which log4net or NLog does the magic while your application happily logs information while not worrying about what is actually taking care of the logging. To me, this is a very interesting method of supporting a tool family – expose the most common methods which a tool supports and let the tool get on with its own business.

What I’d like to see is a community effort to publish an ILogger interface to which various logging libraries can adhere, and an IContainer interface for IoC libraries, and other interfaces for various tool families which have enough common features. In this way, we can enable a new level of code sharing and integration between projects.

(Also published on my personal blog)

Related Articles:

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    This entry was posted in softwaredesign. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

    6 Responses to Common Interfaces for Tool Families

    1. DoniG says:

      For IoC, there is the CommonServiceLocator.

      http://www.codeplex.com/CommonServiceLocator

    2. Steve Sheldon says:

      Isn’t the reason why you have multiple different solutions to some problem is because they offer something different in terms of functionality?

      As such, how can you ever really have a common interface? Any interface will merely support the lowest common denominator of functionality.

      This is why the natural movement in computing is to standardize on one piece of software.

    3. I actually played around with this concept a few times, making a wrapper for typical functions (logging, caching, even tried repositories) in a single project who’s intent was to do nothing but standardize and let you change the underlying framework without changing your code. It’s on Google Code: http://code.google.com/p/nwrapper

      It was a based on a wrapper I developed around Paul Wilson’s O/R Mapper (http://code.google.com/p/wilsonormapper).

    4. I actually played around with this concept a few times, making a wrapper for typical functions (logging, caching, even tried repositories) in a single project who’s intent was to do nothing but standardize and let you change the underlying framework without changing your code. It’s on Google Code: http://code.google.com/p/nwrapper

      It was a based on a wrapper I developed around Paul Wilson’s O/R Mapper (http://code.google.com/p/wilsonormapper).

    5. I actually played around with this concept a few times, making a wrapper for typical functions (logging, caching, even tried repositories) in a single project who’s intent was to do nothing but standardize and let you change the underlying framework without changing your code. It’s on Google Code: http://code.google.com/p/nwrapper

      It was a based on a wrapper I developed around Paul Wilson’s O/R Mapper (http://code.google.com/p/wilsonormapper).