Apollo.Common in Codeplex

19. December 2008 04:53

The past few weeks, I've been working on Apollo.Common, which is meant to provide some easier to use functionality to enterprise applications.  A lot of this functionality, and more is provided by the MS PnP team's Microsoft Enterprise Library.  However, ent-lib tends to be overly complex, difficult to use, and require a lot of customization before you can get moving.  I want Apollo.Common to be easy to use, implement and deploy with a minimal learning curve.

Apollo.Common.Cache started off as a means of providing a simple, consistant method of accessing memcached servers in our applications.  The cache piece is based on the BeIT memcached client, and is extended to support generics, as well as a callback pattern [MC.Cache.Get<T>(string key, Func<T> ifNullCallback)], which reduces a lot of code, apposed to a Get/Check/Set/Return pattern repeated within the applications.  This piece is already available, but as a result of working on this peice spawned two other areas of concern.  One is a common configuration library.  Another is a common logging library.

Apollo.Common.Configuration is intended to decouple settings from applications.  Allowing a single directory with configuration files to be set in a single place across an entire webfarm.  This way applications can be installed, without needed to update/edit, or otherwise change configuration files.  It also allows for common settings, such as logging, memcached, database strings, etc to be configured consistantly in different applications, on the same or different servers in a consistant way.  The configuration files can be named with a {configname}.{environment}.{application name}.{application version}.config pattern, and have narrow, and broad configuration files available.  There is an option to configure these settings within the application, or web.config files.  Environment will be determined based on the app config, environment variable, http request app hostname, machine dns name, machine name in that order.  For the machine dns name, if the name begins with QA or DEV, or has .qa or .dev in the name it will use the appropriate environment.  If it is in debug mode, it will fallthrough to LOCAL, otherwise it will fallthrough to PRODUCTION.  This happens on first access via an application, and is saved in memory.  This makes the library very flexible out of the box, while reducing pain in implementation and use.   I still have a few things to flush out, but it's going fairly smoothly.

Apollo.Common.Logging is a simple wrapper for NLog, that uses Apollo.Common.Configuration to determin the configuration file (in NLog settings format) that should be used.   This piece has the most work left to be done.  I wanted to make it as easy as possible to add logging into the application, while providing the flexibility that the common configuration piece offers.

I hope to get quite a bit more done in this library.  Including supporting a ASP.Net Session, and Cache piece within the cache library.  I've received a lot of feedback already from some of the development teams and managers here, and will work towards integrating some of the suggestions.  I've also outlined some of the todo pieces within the wiki-style pages within the codeplex project.

Comments are closed


Michael J. Ryan aka Tracker1

My name is Michael J. Ryan and I've been developing web based applications since the mid 90's.

I am an advanced Web UX developer with a near expert knowledge of JavaScript.