Introducing IoC To An Existing Application (Continued)

(This is a continuation of a previous post)


In the previous post, we adapted our existing code to allow the use of an IoC Container, and prepared the container so it is ready to use.  In this post, we put that foundation to work and start altering our logic.
Install Service Locator
When coding new applications, Inversion of Control (IoC) is best done using Dependency Injection, or DI.  However, DI assumes all necessary classes are registered with the container and available for resolution.  When converting an existing application, it is not practical to convert all necessary classes to DI in one step.  Trying to do so can dramatically increase the scope of the work, making the conversion project more difficult and possibly extending it beyond a single sprint.

In order to avoid the requirement of converting the entire application at once, we introduce an intermediate step of using a Service Locator.  Using the Service Locator pattern allows you to convert objects to the IoC pattern slowly over time instead of requiring a massive conversion effort.  Once an application is fully converted to Service Locator, it is a trivial step to further convert it to Dependency Injection.

The Service Locator is a static class that is referenced from all parts of the system (this is the part that Service Locator detractors object to).  As such, it needs to be located in a central project that can be referenced by all classes that need it.  Depending on how your IoC container works, this project may also need to be able to reference the projects where the Interfaces and Classes are kept. If you have a large solution, finding a good place to put the Service Locator can be one of the most difficult parts […]

Introducing Inversion of Control To An Existing Application

How to retrofit an existing system to use Inversion of Control and Dependency Injection, without the cost of a rewrite. Reduce maintenance costs for legacy systems.

Updating Legacy VB.NET Applications

Legacy applications are not always extremely old. Sometimes they have just been ignored for a while and in order to reduce support costs they need a polish.
First Things First: Project Options
If you’ve ever worked with a VB.NET project that has been around since the early days of .NET 1.1, you probably had a lot of cleanup to do before applying any of the latest technologies. If this effort is taken haphazardly, it can result in a mess that is difficult to clean up. Taken in the proper order, though, legacy VB.Net can be updated quickly and easily.
Option Explicit = On
The first thing to do is ensure Option Explicit is turned on. This is a property in the VB.NET Compile project page that requires all variables to have an explicit declaration – a DIM statement. When this option is set to Off, variables can be created and used on-the-fly without a formal declaration. This is bad because with Option Explicit = Off, a simple typo in a variable name will cause the compiler to create a new variable by that name, resulting in bugs that are very hard to find.

Note that Option Explicit can also be turned on and off in code! Before setting the project property, scan through your code for “Option Explicit” to see if there are any landmines waiting for you.

To minimize the confusion, set Option Explicit for one project, then build and fix any errors. Normally it only takes a few “DIM” statements to get things working again. Then move on to the next project, making sure to check in your code after each build so you have a “check point”.
Option Strict = On
After setting the Option Explicit = On for all projects, […]

By |October 10th, 2014|Legacy Applications, Reengineering Existing Systems, VB.NET|0 Comments