We've taken over coding on a .NET MVC project, and as I'm relatively inexperienced with many of the MVC design approaches, I'm working on getting a good understanding of the design choices.

One aspect that's caught my attention is that each controller class is initialised using existing instances of services. In my non-MVC past, I usually kick off a service just when I need it, or at most have a service instance for that controller instance.

To show exactly what I mean:

namespace Project.Controllers
    public class AccountController : BaseController
        private readonly IAccountService _iAccountService;
        private readonly ISettingsService _iSettingService;
        private readonly IGenericContentService _genericContentService;
        private readonly IMemberService _memberService;

        public AccountController(IAccountService iAccountService, ISettingsService iSettingService, IGenericContentService genericContentService, IMemberService memberService)
            _iAccountService = iAccountService;
            _iSettingService = iSettingService;
            _genericContentService = genericContentService;
            _memberService = memberService;

I think the below code is what's causing it to init the controllers with the required services:

namespace Project.Framework.Bootstrappers
    public class MyApplicationRegistry : Registry
        public MyApplicationRegistry()
            Scan(assemblyScanner =>

            For<HttpContextBase>().Use(() => new HttpContextWrapper(HttpContext.Current));

My guess is that this improves performance, as you don't need a fresh instance of a service class each time you need it, or even for each controller.

But this design does make the code a bit more unwieldy. Changing a service method requires you to keep both the interface and the class synced, which just makes for a bit more "overhead" for each code change.

There's two other options I see:

  1. Create an instance for each service for each controller. I can see how this could become a problem for a heavily used application, but until then I don't see how it's an issue.
  2. Make the service methods all static so you don't need to create an instance of the class. To me it seems they pretty much are that already. So in my mind, this seems like a nice alternative. But I do suspect a general distaste for static methods these days for reasons I'm still learning.

So how do these options compare? Am I missing something, and why does the above code pattern seem to be fairly popular for .NET MVC?

Looks like this is Dependency Injection

I did a bunch of more reading, and I see that this design is for dependency injection, and uses the StructureMap library. The merits of efficient, decoupled code are quite compelling, so it's seeming like the code I've shown is better than my two options, primarily from a design standpoint but also a performance standpoint.

  • 2
    This seems like some sort of DI, I cant tell the brand from the code you posted. Is your problem that the DI context is set to singleton for the services rather than per request? or have you not come across Dependancy injection before?
    – Ewan
    May 30, 2015 at 21:20
  • I had not come across Dependency Injection before! Did a lot of reading after posting this question, and figured it out. I've updated my question accordingly. Though perhaps the point of static vs shared instances remains.
    – andrewb
    May 31, 2015 at 1:08
  • The only thing worse than an "Edit:" in a Stack Exchange post is an Edit in a Bolded Subtitle. May 31, 2015 at 1:16

1 Answer 1


It looks like Dependency injection has been implemented in the MVC project.

This is considered best practice these days and def superior to your two options!

You would expect the services to be instanciated per request rather than singletons which would persist over all requests. (although these are sometimes used)

However its not really clear that your interpretation of the code is correct. I think its likely that the DI is following best practice and you should read up some more before you think about changing it!

  • Oh really, so each request requires initialisation of the required services? I thought that once the app has started, it'll gradually have instances of services kept in memory, and that half the point of DI was to not have to reinitialise all these common services for each request.
    – andrewb
    Jun 1, 2015 at 0:16
  • DI is just for code structure. I wouldnt recomend singletons in a web server. Normally you dont want to share data over requests. If you have expensive initialization a cache is prob more appropraite
    – Ewan
    Jun 1, 2015 at 7:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.