Factory pattern using built-in dependency injection of ASP.Net Core
Factory pattern is a creational design pattern that solves the problem of creating object without exposing the creation logic to the client.
Standard Way
When I first read about factory pattern and saw its naive example it was simple and easy to grasp. Before we see how we can create our factory to create instances via ASP.Net Core DI let just revise how we used to achieve factory pattern naive way.
Let’s try to take a real world example so that we can relate it more easily. We have a service contract for stream service which exposes only one method for now say show movies.
Now, we have two services which implements the above contract namely Netflix stream service and Amazon stream service.
Say, on the basis of user selection we want the appropriate service to be instantiated on a controller(or any client) say Movies controller. Here our controller would be dependent upon a factory to get the instance. A typical factory would look something like this:
Now, in our client class or Controller class we can create instance of StreamFactory class and pass the user selection to get the appropriate instance of IStreamService and everything works out for us. This simple factory is able to hide the logic of creating instances and accomplish our requirement.
If you’ve worked with ASP.Net core apps you would know that dependencies get resolved at runtime using IoC container of ASP.Net core. We register all our app dependencies in the Startup class.
Startup ConfigureServices will have only dependency registered there.
A Twist
Things becomes complicated when NetflixStreamService and AmazonStreamService will have their own dependencies in their constructors. In that scenario StreamFactory would have to resolve those dependencies and then things become messy. We want to rely on IoC container of ASP.Net core to resolve our dependencies and don’t want to change our factory every single time a new dependency is introduced in either of the StreamService.
Modern Way
We want our factory to be smart it should only resolve which concrete class is required to be instantiated, it should ask built-in service container of ASP.Net core to get the instance and resolve its dependencies.
Let’s update our factory.
Here, our factory is dependent upon IServiceProvider to get the instance of StreamService and it would IServiceProvider’s responsibility to resolve all the dependencies requires by any of the StreamService.
But before things magically works out we need to modify our Startup.cs to register NexflixStreamService and AmazonStreamService in ConfigureServices method, so that DI of ASP.Net core could figure out the required dependencies by either of the service and could resolve them at run time.
We don’t need to change anything in the Controller and everything works exactly like before.
Conclusion
We took the help of DI of ASP.Net core to resolve all dependencies yet we were to decide which StreamService would be instantiated via help of Factory where our business logic resides.
With your support, I can keep creating and sharing my work with the world. I would appreciate you buying me a coffee.
