0

I'm building an MVC 3 site, and want to use Spring to provide run-time injection of my web service adapters, so that I can stub in mock service calls instead of calling the real deal.

var ctx = ContextRegistry.GetContext();
var serviceAdapter = (IServiceAdapter) ctx[Constants.C_ServiceAdapter];
...
serviceAdapter.doSomething();

I've been stung before on Spring thread-safety, where singleton is not "false", so looked at the Spring source to double check that the above was thread safe.

The source has this in the comments:

/// A singleton implementation to access one or more application contexts.  Application
/// context instances are cached.
/// </p>
/// <p>Note that the use of this class or similar is unnecessary except (sometimes) for
/// a small amount of glue code.  Excessive usage will lead to code that is more tightly
/// coupled, and harder to modify or test.  Consider refactoring your code to use standard
/// Dependency Injection techniques or implement the interface IApplicationContextAware to
/// obtain a reference to an application context.</p>

My question: why is using this ill-advised? Is it just because of the 2 lines of boiler plate that we don't need? AFAIK I'm still declaring what object will finally be created in the config, so don't see how it makes it any more tightly coupled?

Note: I don't really want to go down the route of using the Spring.Web dll and doing all of my DI through the config, if I can help it!

Thanks a lot Duncan

Duncan
  • 10,218
  • 14
  • 64
  • 96

1 Answers1

2

It's a bad idea because you are not using dependency injection. It's not because of any thread-safety considerations of the GetContext method. You are using the service locator pattern which is considered bad practice - the classes should not be responsible from querying the DI container to fetch dependencies, those dependencies should be injected.

As a best practice you should consider writing a custom dependency resolver based on Spring.NET. This way dependencies will automatically be injected into controllers and other classes.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • Thanks, that makes sense - the component doing the "hot-swapping" needs to be "hot-swappable" itself! I'm only calling using this 3 times in my whole app so writing a dependency resolver seems a bit overkill for this but will try and implement it here (time permitting!) – Duncan Sep 17 '12 at 15:49
  • 1
    +1, but note that spring 1.3.1 and [higher come with support for mvc 3.0](http://www.springframework.net/doc-latest/reference/html/web-mvc3.html) including an [implementation of IDependencyResolver](https://github.com/SpringSource/spring-net/blob/master/src/Spring/Spring.Web.Mvc3/SpringMvcDependencyResolver.cs) – Marijn Sep 17 '12 at 18:57