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)


Posted Nov 13 2008, 11:05 AM by cramsay
Filed under:

Comments

Common Interfaces for Tool Families wrote Common Interfaces for Tool Families
on 11-15-2008 5:56 PM

Pingback from  Common Interfaces for Tool Families

DoniG wrote re: Common Interfaces for Tool Families
on 11-15-2008 7:54 PM

For IoC, there is the CommonServiceLocator.

www.codeplex.com/CommonServiceLocator

Jarda wrote re: Common Interfaces for Tool Families
on 11-16-2008 2:15 AM

For logging there is:

netcommon.sourceforge.net

Steve Sheldon wrote re: Common Interfaces for Tool Families
on 11-16-2008 7:16 PM

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.

Reflective Perspective - Chris Alcock » The Morning Brew #224 wrote Reflective Perspective - Chris Alcock » The Morning Brew #224
on 11-17-2008 2:26 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #224

Dew Drop - November 17, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - November 17, 2008 | Alvin Ashcraft's Morning Dew
on 11-17-2008 6:58 AM

Pingback from  Dew Drop - November 17, 2008 | Alvin Ashcraft's Morning Dew

Brian DeMarzo wrote re: Common Interfaces for Tool Families
on 12-03-2008 2:33 PM

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: code.google.com/.../nwrapper

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

Brian DeMarzo wrote re: Common Interfaces for Tool Families
on 12-03-2008 2:34 PM

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: code.google.com/.../nwrapper

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

Brian DeMarzo wrote re: Common Interfaces for Tool Families
on 12-03-2008 2:35 PM

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: code.google.com/.../nwrapper

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

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

Enter the numbers above:
Copyright Los Techies 2008, 2009. All rights reserved.
Powered by Community Server (Commercial Edition), by Telligent Systems