/// Tuesday, November 8

Dependency Injection and Scripted Configuration for Enterprise Development - Part 1

Summary

This article describes how script-like configuration files and the Dependency Injection pattern (DI) prevent many of the issues encountered when building an enterprise-level application. Two relatively unknown and powerful open source technologies are used: NanoContainer.NET IoC framework and the agile .NET language Boo.

Application Configuration

An application typically configures itself by retrieving settings from a static configuration file in the form of XML, property files, registry values or some other text format. The setting values are used to instantiate objects, then objects are wired together to perform the functions of the application. If implemented poorly, this infrastructure logic is the source of many bugs and wasted man hours. Even when implemented properly the infrastructure logic is intertwined with business logic deviating from the Separation of Concerns principle.

The dependency injection pattern (DI), in practical terms, is the opposite. DI injects dependencies into an application instead of the application pulling and building its dependencies in code. DI injects pre-wired, ready-to-use objects into an application. The application simply asks for a database connection from a managed container instead of retrieving a connection string then instantiating a database connection object. An application simply uses a pipeline object containing wired pipes and filters without having any knowledge of sequence or how to instantiate pipes and filters. The developer focuses on business logic. Factories, singletons become redundant. Unit testing is easier as mock objects are easily injected without any change to the application.

I use the term DI very loosely. DI is not a design pattern in the sense that it can described within a UML class diagram. DI is a methodology. DI is the fundamental principle behind Inversion of Control (IoC) frameworks. These frameworks not only build and instantiate objects, they provide additional benefits such as interceptors, object pooling, objects lifecycles, etc.

Application Deployment

Most medium to large teams deploy aplications to different server environments as an application matures in the development cycle. Environments have a similar network infrastructure and run the same version of software as the actual production environment. Each environment serves a specific purpose whether it be for integration, testing or staging for actual deployment. Here are some common environments utilized within a development cycle:

PERSONAL

Individual developer box with isolated database, web server, etc. Virtual machine software is an indispensible tool for emulating the servers found in production.

DEV

An application is deployed to DEV when a developer has met all requirement for his task including successful unit tests. Developer's are usually given admin access to servers in this environment to facilitate diagnosis of issues that surface. Preliminary black-box testing is performed against this environment in preparation for formal testing. (Try to run the same tests as QA). Developers must resist the urge to deploy a single web page or assembly. Fully automated installations are a must.

TEST

The quality assurance (QA) team's environment. Developers do not have server access to this environment. Installation, database script issues, trivial bugs should have been caught in the DEV environment. The QA team tests the application at a much higher level and more than likely different than developers ensuring the application meets business requirements. It behooves the development team to build or reuse a logging framework to not only log diagnostic messages but also have a website/tool to view and query the logs.

PROD

The exact same application bits passed in TEST are deployed to PROD. The logging threshold is increased to log info and errors.

What can go wrong? Many things, and it will! Some of the culprits are access permissions, invalid or missing configuration settings, DLL hell (Java and .NET too), different software on the servers, bad network connection, missing keys in the database, human error, etc---so much can go wrong.

To be continued...

In the next article I'll detail how configuration scripts, written in any .NET supported language (Boo, C#, VB, J#, JavaScript and VBScript), and the NanoContainer.NET IoC framework alleviate configuration and deployment issues. I'll cover Boo specifically as it provides additional benefits over C# and VB.NET.

Comments:

Java does not suffer from DLL hell, since DLLs are specific to Microsoft Windows.
 
No, but it can suffer from JAR hell, which is basically the exact same issue as DLL hell.
 
Java on Windows can suffer DLL hell and JAR hell.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?