Dependency Injection migration path to 8.2

Question

With native support for Dependency Injection in Sitecore 8.2, what is the easiest path for upgrading from previous versions in solutions utilizing a third party DI framework (Castle Windsor, SimpleInject etc.), if the goal is to make use of the built in DI?

Should we migrate to Microsofts Dependency Injection framework in the existing solution prior to the upgrade? Or can we easily upgrade with the current DI framework and migrate later?

Update

The current solution is a simple implementation of a Unity container, so I do not expect to be missing out on any features when migrating.

Answer 1

In my experience, when you plan major changes in your solution, the worst thing you can do is apply all of them at once. When you inevitably run into problems, you won't know which of the changes caused them; that will make debugging and fixing so much harder.

Generally, the most reliable approach is to split your changes into as many small steps as possible. After you apply a single step, you'll be able to test if everything in the solution still works properly. You'll be able to fix issues related to that particular step in an isolated manner—without other changes, and unrelated issues, standing in the way.

Suggested approach

I propose that you split your upgrade process into four stages:

1. Upgrade to 8.2

When you upgrade, your current DI container integration will still work. Hence, you can perform the upgrade process and debug upgrade-specific issues without having to worry about DI integration changes.

2. Replace Sitecore's MS DI with your current container

At this stage, you will replace Sitecore's underlying container with the one you've been using. I wrote an article that describes how to do this:

Replacing the Default DI Container in Sitecore 8.2

If you are using SimpleInjector, check out this answer by Richard Seal for an extra required step.

Once you've replaced Sitecore's container, nothing in the app should break (in most cases), as your application code will still use your custom DI approach. So the DI container will be configured in two separate ways: directly with ASP.NET MVC, and in Sitecore internally.

3. Migrate your service registrations to use the Sitecore way

Change the way you register services from your DI container's API to Sitecore's configurators or direct registration.

After you've completed this step, removing your DI container's integration with ASP.NET dependency resolver should not break anything. This is because all of your services will be wired up through Sitecore, which will already have its dependency resolver hooked into MVC.

4. Switch Sitecore's DI container back to MS DI

Remove your DI container from the solution and revert Sitecore to use Microsoft's default dependency injection implementation.

This should go smoothly, since the Sitecore way of registering services works with any DI container configured in Sitecore. You services will now be injected in your controllers and modules via Sitecore and MS DI.

Conclusion

It may sound like some extra work, but I believe that this is the most reliable way, since you'll have to worry about fewer simultaneous issues at any given point in time.

Answer 2

One might think that there is already a similar question on this matter. However, your exact question is a bit different.

An Upgrade Approach

As far as unwiring the existing DI containers (and updating Sitecore), I would start with trying to eliminate upgrade complications first.

1. Start with just removing your old DI completely.

While this may seem like a backwards approach, upgrading to Sitecore 8.2 with a DI container already in place, or customizations to the MVC Controller Initializer in the initialize pipeline, can complicate the upgrade. So, unwiring it to begin with can remove an upgrade variable.

2. Upgrading your environment to 8.2 (or fresh install depending on your approach)

Perform the upgrade to your needs. If coming from anything before Sitecore 7.2, consider a fresh install. If coming from 7.2 directly, consider the Migration Tool. Anything past 7.4, follow upgrade path documentstion.

3. Applying your controllers and modules following Kam's blog.

Now with Sitecore upgraded and the default MS DI in place, you can wire your controllers and modules back in using the configs.

Background Info

There are a couple approaches, but you don't have to "upgrade to MS DI" in order to use it. Instead, Sitecore has created a series of configuration files that allow you to patch in your DI elements. As long as you don't need any real elegant work registering controls, you should be ok.

In my opinion Kam Figy wrote the leading blog post on how to work with the Sitecore MS DI. This should help you understand how to do the config.

Additional Approaches

The other question that is of a similar subject matter, linked above, has a really great answer on understanding what you can do with it.

One of those approaches is using your current DI in addition to the Sitecore DI.

A second approach is to unwire the MS DI from Sitecore and implement using your own.

Mileage may vary, and your exact solution is going to be heavily influenced by your current container needs and existing code base.

Shaving Yaks

As with anything, this is an approach. There are others, and the right approach really depends on your solution and the intricacies of it.

Answer 3

As others have suggested, it's often easier to make this kind of architectural change slowly rather than going for the big bang. There's nothing stopping you from continuing with your current container, then as you write new classes (or just take 1 class at a time), migrate the class over to Sitecore DI. Of course you'll need to ensure any services you require are registered into the Sitecore container, so you may need to populate both your current container and the Sitecore DI container for this approach to work. And that's assuming you can withstand the transition period of having 2 containers in the solution at once.