Question

In general does the instantiation of classes with methods, but no fields or properties, have much overhead?

I’m developing an ASP.NET MVC application that heavily uses constructor injection and some controllers have up to 10 dependencies so far. But due to the high number of dependencies, I resorted to a IMyAppServiceProvider interface and class that provides generic access to all the dependencies, through the DependencyResolver in MVC 3.

I ripped out all my application specific code and created a Gist with my basic setup (This doesn’t include the BaseController setup mentioned below though).

I also created a BaseController class that accepts the IMyAppServiceProvider. All controllers inherit from this base class. The base class takes the IMyAppServiceProvider object and has protected variables for all of the various services. Code looks something like this:

public class BaseController
{
    protected IService1 _service1;
    protected IService2 _service2;
    protected IService3 _service3;
    // ...

    public BaseController(IMyAppServiceProvider serviceProvider)
    {
        _service1 = serviceProvider.GetService<IService1>;
        _service2 = serviceProvider.GetService<IService2>;
        _service3 = serviceProvider.GetService<IService3>;
        // ...
    }
}

This makes the code for the controllers “squeaky clean”. No private/protected variables, no assignments in the constructor, and the services are referenced by the base class protected variables. However, every request will instantiate every single service that my application uses, whether or not the specific controller uses all of them.

My services are simple and just contain method calls with some business logic and database interaction. They are stateless and have no class fields or properties. Therefore, instantiation should be fast, but I’m wondering if this is a best practice (I know that’s a loaded term).

Answer 1

every request will instantiate every single service that my
application uses, whether or not the specific controller uses all of
them.

I believe you’ve answered your question yourself, this is not a good approach.
Moreover using such kind of dependency resolving (Service Locator injection) is a bad practice since Controller’s API becomes messy. Controller clients are not aware of which services really necessary for a specific controller so you might end up with unexpected run time errors, unit testing will be a mess as well.

BTW one more suggestion – mark all classes which are considered to be a base class by abstract keyword, in this way you can avoid using it as a concrete class. Designing and implementing a base class is a concrete design decision, so make your design intentions clear.

Regarding a cost of instantiation, in your case it would not make a big difference, but in general to reduce a cost of heavy objects instantiation you can:

• Use Prototype pattern to “avoid the inherent cost of creating a new object in the standard way (e.g., using the ‘new’ keyword) when it is prohibitively expensive for a given application” (c) Wikipedia
• Use Lazy Initialization for services which are not needed from the start of the owner object life time, so those would be initialized on demand. Since .NET Framework 4.0 yo can use built in Lazy(T) class