Share service instances amongst all controllers?

Question

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 =>
             {
                 assemblyScanner.TheCallingAssembly();
                 assemblyScanner.WithDefaultConventions();
             });

            For<HttpContextBase>().Use(() => new HttpContextWrapper(HttpContext.Current));
            For<MembershipProvider>().Use(Membership.Provider);
        }
    }
}

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.

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!