Constructor dependency injection in the base class

Question

I am creating a base repository class with the Entity Framework where it inherits the entire Entities repository. I want to inject a DatabaseContext into a base class using Injection Dependency using Ninject. I think the Injection constructor is the right way, but when executing the Constructor Injection in a derived class, I have to pass the parameter to the constructor in the base class, and I don't want that. So is a setter injection more appropriate?

Here is my code:

 public abstract class BaseRepository<TEntity> : IDisposable where TEntity : class { private readonly DatabaseContext _databaseContext; protected BaseRepository(DatabaseContext databaseContext) { this._databaseContext = databaseContext; } } 

Using the Injection constructor in the above example, in my derived class I have to pass the BaseContext object to the base class, I do not like to do this with the whole derived class :

 public class UsuarioRepository : BaseRepository<IUsuario>, IUsuarioRepository { public UsuarioRepository(DatabaseContext databaseContext) : base(databaseContext) { } } 

Embedding a Setter instead of a Constructor Injection is a good way to solve this? What is the best way?

Update:

Using Setter Injection, my derived class will not have constructors:

 public class UsuarioRepository : BaseRepository<IUsuario>, IUsuarioRepository { } 

My context is just one application. I don’t need a derived class to pass a context object, but I like to introduce it into the base class to use mocks for tests in the future.

Solve the problem of:

Sorry, I'm confusing the question, but I solve my problem by creating Factory:

 public abstract class BaseRepository<TEntity> : IBaseRepository<TEntity> where TEntity : class { private readonly ContextFactory _contextFactory = new ContextFactory(); protected DatabaseContext CurrentContext { get { return this._contextFactory.GetCurrentContext(); } } } 

And my derived class will look like this:

 public class UsuarioRepository : BaseRepository<IUsuario>, IUsuarioRepository { } 

And My Factory like this:

 public class ContextFactory { public DatabaseContext GetCurrentContext() { return new DatabaseContext(); } } 

Answer 1

Nesting implies that dependency is optional, and design injection means that dependency is required. Select the template accordingly.

In more than 95% of cases, the Injection constructor is the correct template. What do not you like?

Answer 2

I do not think there is a “better way”.

Embedding a constructor and an installer is not exactly equivalent, as injecting an installation gives you a little more flexibility. This is how I choose between them:

Suppose you created object A, and A needs object B to work. The question to be asked is: is it possible for A to exist / be created without reference to B? Is this a valid state for an object A not to have B? Sometimes it does not make sense for A to have zero B, then constructor injection is the best solution. If, it is normal for B to be assigned A later, and not necessarily at build time, then go with the installer's injection. It all depends on the domain that you are trying to simulate, and the answers will vary from situation to situation.

Answer 3

Indeed, I do not see a problem with passing a parameter to the base class. But if this is an absolute requirement, you can always do this:

 public abstract class BaseRepository<TEntity> : IDisposable where TEntity : class { protected BaseRepository() { } protected abstract DatabaseContext GetContext(); } 

Your derived classes may now look like this:

 public class UsuarioRepository : BaseRepository<IUsuario>, IUsuarioRepository { private DatabaseContext _databaseContext; public UsuarioRepository(DatabaseContext databaseContext) { _databaseContext = databaseContext; } protected override DatabaseContext GetContext() { return _databaseContext; } } 

Now you can have a constructor injection without passing a parameter to the base constructor. But it is really the same.

I honestly don't like the idea of ​​installing setter, because it looks like DatabaseContext is a necessary dependency. For the required dependencies, inject the constructor. If this were not necessary, then by all means, go ahead and inject the unit. Strike>

EDIT:

Due to our long conversation in the comments, I better understand what you are trying to accomplish.

If you want to separate your derived classes from the DatabaseContext, you might be better off constructing it in different ways. It is difficult to separate the derived class from its dependencies of the base class, and if you think that they should be decoupled, then you will have a better design that does not use inheritance at all.

 public class BaseRepository<TEntity> : IDisposable where TEntity : class { public BaseRepository(DatabaseContext context) { } } 

Now your derived classes (which will no longer be retrieved) look like this:

 public class UsuarioRepository : IUsuarioRepository { public UsuarioRepository(BaseRepository<IUsario> repository) { } // Implement other methods here } 

You can now have one base class that uses the DatabaseContext, and your derived classes no longer depend on it.

Answer 4

All three methods: 1. Counter-constructor, 2. Setter, and 3. Interface Injection has its advantages and disadvantages, depending on the situation that needs to be used. If I were you, I would go with a setter, although an interface might also be a good choice.

I ask you to go through this article http://www.devx.com/dotnet/Article/34066