Constructor injection and initialization of dependencies being injected

Question

I am writing a simple console application that takes care of connecting to the database, selecting a particular product from it (based on the provided criteria) and doing some processing with this product. I am storing command-line arguments to an instance of this class:

public class Arguments { public string ConnectionString { get; set; } public int ProductId { get; set; } public string ProductName { get; set; } }

At some point, I need to fetch the product from the database. I am using the following repository for that:

public interface IProductRepository { Product GetById(int productId, string connectionString); Product GetByName(string productName, string connectionString); }

Then, I inject an implementation of the repository to the class that uses it, e.g:

public class ProductProcessor { private readonly IProductRepository productRepository; public ProductProcessor(IProductRepository productRepository) { this.productRepository = productRepository; } public void Process(Arguments arguments) { Product productToProcess; if (!string.IsNullOrEmpty(arguments.ProductName)) { productToProcess = productRepository.GetByName(arguments.ProductName, arguments.ConnectionString); } else { productToProcess = productRepository.GetById(arguments.ProductId, arguments.ConnectionString); } // .... } }

This is working, but what I don't like about the design is that every method of the IProductRepository has a connectionString argument. If there was no dependency injection involved, I would probably rewrite it like the following:

public void Process(Arguments arguments) { Product productToProcess; ProductRepository productRepository = new ProductRepository(arguments.ConnectionString); if (!string.IsNullOrEmpty(arguments.ProductName)) { productToProcess = productRepository.GetByName(arguments.ProductName); } else { productToProcess = productRepository.GetById(arguments.ProductId); } // .... }

This enables me to have simpler and easier-to-use interface. Of course, now the ProductRepository does not have parameterless constructor and it is difficult to use with DI container. Ideally, I would like to have the best of both worlds, i.e. to initialize the ProductRepository with the connection string from constructor and remove the connection string from its methods. What is the best approach to achieve this?

Some approaches I've already considered:

Add a method Initialize(string connectionString) to the IProductRepository that would basically serve as a constructor. Obvious drawback is that I now need to check whether the Initialize has been called before doing anything in GetById or GetByName methods.
Do not use constructor injection and use Service Locator pattern instead to instantiate ProductRepository. I don't like Service Locator much, but this is probably only possible solution.

Is there any better alternative?

EDIT: From the answers I see that I should have posted a bit more context. I am using Ninject as my DI container. In Main method in my Program.cs, I register all dependencies to the container and instantiate the class that serves as an entry-point to the application:

public static void Main(string[] args) { StandardKernel kernel = new StandardKernel(); kernel.Bind<IArgumentsParser>().To<IArgumentsParser>(); kernel.Bind<IProductProcessor>().To<ProductProcessor>(); kernel.Bind<IProductRepository>().To<ProductRepository>(); MainClass mainClass = kernel.Get<MainClass>(); mainClass.Start(args); }

The MainClass looks like the following:

public class MainClass { private readonly IArgumentsParser argumentsParser; private readonly IProductProcessor productProcessor; public MainClass(IArgumentsParser parser, IProductProcessor processor) { argumentsParser = parser; productProcessor = processor; } public void Start(string[] args) { Arguments parsedArguments = argumentsParser.Parse(args); productProcessor.Process(parsedArguments ); } }

This enables me to have a dependency to Ninject and creation of the whole graph in one place only (the Main method) and the rest of the application knows nothing about DI and containers.

I'd like to keep it that way, if possible.

Community · Accepted Answer · 2017-05-23 10:29:56Z

I agree that the current interface design is a leaky abstraction, so let's define it like this instead:

public interface IProductRepository { Product GetById(int productId); Product GetByName(string productName); }

What you need then is an Abstract Factory that can create an instance of IProductRepository for you.

So ProductProcessor could look like this:

public class ProductProcessor { private readonly IProductRepositoryFactory productRepositoryFactory; public ProductProcessor(IProductRepositoryFactory productRepositoryFactory) { this.productRepositoryFactory = productRepositoryFactory; } public void Process(Arguments arguments) { Product productToProcess; var productRepository = this.productRepositoryFactory.Create(arguments.ConnectionString); if (!string.IsNullOrEmpty(arguments.ProductName)) { productToProcess = productRepository.GetByName(arguments.ProductName); } else { productToProcess = productRepository.GetById(arguments.ProductId); } // .... } }

Isn't connection string leaky abstraction as well? You've stated this in your book. Perhaps, this isn't as clear-cut in cases like this (connection string as user input)?
Yes, you could argue that, but I just used the OP's object model for that part in order to not mess up everything all at once :)

devdigital · Accepted Answer · 2012-09-03 11:08:35Z

I'm not sure why you need to model the command line arguments at all? You should minimize the dependencies on each of your types. This means the product repository should take the connection string as a constructor parameter (because it's a required dependency), and your product processor should take the product id and product name (if this is the best way you feel to do dynamic queries).

Therefore, assuming your product repository is a singleton, you would new it up at the point you do your registrations (passing in the connection string), and then register this in your IoC container against your abstraction.

You could then new up a product processor (passing in the product id and product name) and register this as singleton against an abstraction. You can then use constructor injection to pass the product processor into any type that requires it.

Please, see the edit I've made. I apologize for not having provided this information in the original question. The problem is that at the point I register dependencies to the container, I don't yet know the value of connection string. The same applies for product id and name.
Don't the connection string, product id, and product name come from the command line arguments? I.e. the 'args' parameter to your Main method? The point at which you register your types in the container? You just need to change your registrations to use instances that you instantiate in your Main method.

Steven · Accepted Answer · 2012-09-03 11:22:28Z

Of course, now the ProductRepository does not have parameterless constructor and it is difficult to use with DI container.

On the contrary, most DI containers allow you to work with parameterized constructors. In fact, when doing Dependency Injection, constructor injection is the advised approach, which means you will have non-default constructors. Having a constructor that takes in a primitive type (such as a string dependency), might mean that some containers won't be able to do auto-wiring for you. Auto-wiring means that the container will figure out what to inject. However, with your product repository, this problem can easily be solved by supplying a initialized instance to the container (if you need a single instance), or supplying a factory delegate (if you need a new instance on each call). It depends on which framework you use, but it might look like this:

container.RegisterSingle(new SqlProductFactory("constring"));

When you supply the connection string in the SqlProductFactory's constructor, you won't have to pass it in (using method injection) to the factory, and you don't need this connection string in your Arguments class.

Could you please check out the edit I've made? I am using Ninject and the edit details the exact way I am doing it. How would your answer apply in that context?

It's actually me · Accepted Answer · 2012-09-04 06:22:04Z

What you can do is to decouple object creation from object look up. The DI container will look up for instance you have registered at the start up. At that point you can pass in the connection string as a constructor argument to your repository.

This is how the product code would look like;

public class ProductRepository : IProductRepority { private readonly string connString; public ProductRepository(string conn) { connString = conn; } }

You can wrap connection string with another type too if needed. The important point is, DI will inject instances required based on the binding done at the type graph during start up. Based on the registration you can simply extract connection string from the args and pass it along the ProductRepository registration.

I have no configuration file - the connection string is stored in Arguments instance. I could add a IDbConnection dependency, but I feel that it would just move the problem from IProductRepository to IDbConnection.
Does that mean the connection string varies from each argument? If not, you do not need to pass it via argument.

Community · Accepted Answer · 2017-05-23 11:55:15Z

EDIT

See the following answer for how to solve you stated problem.

However, I would really recommend using an existing IOC package, such as Windsor or nHibernate. See https://stackoverflow.com/questions/2515124/whats-the-simplest-ioc-container-for-c for some details.

END EDIT

Why not add ConnectionString as a Property to IProductRepository.

So the interface is:

public interface IProductRepository { string ConnectionString { get; set; } Product GetById(int productId); Product GetByName(string productName); }

And the processor becomes:

 public void Process(Arguments arguments) { Product productToProcess; var productRepository = new ProductRepository { ConnectionString = arguments.ConnectionString}; if (!string.IsNullOrEmpty(arguments.ProductName)) productToProcess = productRepository.GetByName(arguments.ProductName); else productToProcess = productRepository.GetById(arguments.ProductId); // .... }

Using the property is exactly the same as using the Initialize method (I mention it in my question). I'd like to avoid it, if possible, because of reasons stated in the questions.

Collectives™ on Stack Overflow

Constructor injection and initialization of dependencies being injected

5 Answers 5

2 Comments

2 Comments

1 Comment

2 Comments

1 Comment

Hot Network Questions

Collectives™ on Stack Overflow

5 Answers 5

2 Comments

2 Comments

1 Comment

2 Comments

1 Comment

Related