0

I am starting to work with DI/IoC and I have some troubles understanding all the concepts.

I have chosen Autofac because it seems it's one of the few that supports both .Net 4.6+ and .Net Core. It seems it also most widely used.

1) Constructor injection - for e.g. in Controllers or my WCF services I understand that it is impossible to do constructor injection to an object that I am instantiating in my code, meaning it is not automatically instantiated.

2) Property injection I would like to do something similar to how you do it in Ninject:

[Inject]
public IWeapon Weapon { get; set; }

And as I understund, in Autofac. it is equivelanet to:

builder.RegisterType<Weapon>().As<IWeapon>().PropertiesAutowired();

1. Now, why is the constructor injection the preferred way?

For example, I have:

  • Factory for repositories
  • Factory for business engines

Those factories, are just one-liners that should do something like (from another IoC):

public class DataRepositoryFactory : IDataRepositoryFactory
{
    T IDataRepositoryFactory.GetDataRepository<T>()
    {
        return ObjectBase.Container.GetExportedValue<T>();
    }
}

Some methods require both, some do not. Doing something like:

public SampleControllerOrManager(IUnitOfWork unitOfWork, IRepositoryFactory repositoryFactory, IBusinessEngineFactory engineFactory)

seems like a waste of resources.

I understand that this helps with testing (?).

But this looks cleaner:

public SampleControllerOrManager(IUnitOfWork unitOfWork)

[Inject]
public IRepositoryFactory RepositoryFactory { get; set; }

[Inject]
public IBusinessEngineFactory EngineFactory { get; set; }

2. Injecting Entity Framework DbContext into the repositories

I want to register the context with the Container and have that injected into the object constructors of the UnitOfWork and the Repository's. I want to be sure the same instance is injected into all the objects. How do I do it in Autofac?

    public class Repository : IRepository {
        //context injected here
        public Repository (DbContext context){ ... }
    }

    public class Manager {
        public void SomeMethod(){
            IRepository = RepositoryFactoryGetDataRepository<ISomeTypeRepository>
        }
    }
cantdoanything33
  • 179
  • 9

1 Answers1

1

Constructor Injection

Constructor injection is the preferred way because it makes them obvious. You can't instantiate the class if you do not provide the required dependencies.

With property injection dependencies are hidden and you could instantiate the class with some missing injections which could lead you to believe that the class is fully initialized and ready to be used. Eventually, you could get an error if you try use a functionality that needs a missing dependency.

Instance Scope

To be sure that the same instance is injected, you could register your DbContext as Singleton. For example:

var builder = new ContainerBuilder();
builder.RegisterType<DbContext>().SingleInstance();

Or, depending on your needs, you could register it using the Instance Per Request scope:

var builder = new ContainerBuilder();
builder.RegisterType<DbContext>().InstancePerRequest();

Note: You may find this article written by Martin Fowler useful.

Community
  • 1
  • 1
Laurent De Cant
  • 493
  • 1
  • 4
  • 19
  • As in my example in p.1, what if not all of the depndancies are always needed? – cantdoanything33 Apr 23 '18 at 11:12
  • 1
    Because they are not used in every methods of a class, it doesn't mean that they are optional. They are still required for the object to fully work. – Laurent De Cant Apr 23 '18 at 11:16
  • DbContext connot be a singleton, it is against everything. Managers/Controllers are per request, meaning new instance is created every time an operation is requested. In the scope of that operation, one DbContext should be injected into every repository that is requested inside. I think I should use something like "per lifetime scope". – cantdoanything33 Apr 23 '18 at 11:24
  • What is the purpose of property injection if not resolving dependancies that are not alway required? I dont get it. – cantdoanything33 Apr 23 '18 at 11:25
  • 1
    It is sometimes useful when, for example, you use a framework that instantiates classes for you but doesn't let you provide custom factories to do the job. Without property injection, you could not inject the desired dependencies. In my opinion, it's more like a workaround. You should use constructor injection if possible. If not, use property injection. – Laurent De Cant Apr 23 '18 at 11:29
  • Well, then the factory pattern that I introduced in p.1 is also a bad practice because it hides the depondancies? I should explicitly inject all the required repositories in the constructor instead of injecting factories? – cantdoanything33 Apr 23 '18 at 11:33
  • We need one, same instance of DbContext per UnitOfWork, then it should disposed. Not one global DbContext. – cantdoanything33 Apr 23 '18 at 11:35
  • I am trying to properly implement this: https://stackoverflow.com/questions/16064902/dependency-injection-in-unit-of-work-pattern-using-repositories/16085891#16085891 – cantdoanything33 Apr 23 '18 at 11:40
  • 1
    No, the factory pattern is not a bad practice. The dependencies are not hidden, they are visible to anyone wishing to instantiate the factory. I would say that delegating a responsibility to a specific class is a pretty good practice and is the first principle of SOLID. – Laurent De Cant Apr 23 '18 at 11:44