6

I seem to need this a lot.

Let's say I have a class with constructor taking several arguments. Some of these can be resolved by registering components. But the rest are instances created during runtime (e.g. fetching an entity from database).

Can Autofac deal with these situations in a nice way? Or is my design sub-optimal?

To clarify, I have classes that have constructors like this:

public MyClass(IService1 service1, IService2 service2, Data1 data1, Data2 data2)
{
//...
}

And I would like to do something like this:

container.Resolve<MyClass>(data1, data2);

Kristof U.
  • 1,263
  • 10
  • 17
Kugel
  • 19,354
  • 16
  • 71
  • 103
  • Related: http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-object. – Steven Jun 07 '11 at 19:12

2 Answers2

10

You can handle this elegantly by registering a factory method in the Autofac container. You resolve the factory method, and then use it to create instances with your runtime dependencies. You can do this yourself by registering and resolving delegates or custom factory types. However, Autofac has explicit support for delegate factories.

There is not enough information to comment on your design. I'll leave that to you :)

bentayloruk
  • 4,060
  • 29
  • 31
4

I would say your design is sub optimal.

You seem to be mixing to things. Dependency injection (using a container) should mainly be used for injecting service components into other components. Don't inject thing like entities, because it is not up to the container to manage their lifetime. Rather, inject a service that can manage entities for you, such as a repository. Although topic of discussion, I would neither inject a unit of work, but rather a factory for creating unit of works. This way your application manages the lifetime of the unit of work explicitly.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • I'm not injecting entities. I just have classes that requires services, but also concrete data instances. – Kugel Jun 08 '11 at 13:12
  • Try to separate data and behavior in this case. Don't use constructor injection to inject data objects (DTOs) into services and don't inject services into DTOs. Just return DTOs from services or call service methods using DTOs. – Steven Jun 08 '11 at 14:43
  • So your suggesting that classes are either services or data objects? – Kugel Jun 08 '11 at 15:11
  • As I said, whether you should inject a unit of work or a repository is topic of discussion. I wrote this answer two years ago and since then changed my mind. For the applications I build right now, I find it more convenient to inject a unit of work directly as I expressed in [this stackoverflow answer](http://stackoverflow.com/questions/10585478/one-dbcontext-per-web-request-why). – Steven Sep 28 '13 at 22:10
  • 1
    Thanks for amending your answer. I should note that when I posted this question a I was dealing with a stateful WPF application, which is not a very good place to start with IoC, because there's lot's of object creation in response to user actions during runtime. In the end I dealt with it using overload of `BeginLifeTimeScope` which takes additional configuration. I had 3 or 4 nested scopes which were configured with extra services on demand. – Kugel Sep 29 '13 at 23:08