How to provide one of several constructor dependencies from a factory method?

I’m sitting with service fabric, and are wondering how to apply dependency injection in a good way…

The reliable services has a CreateServiceInstanceListeners-method that you override to provide the different listeners for the service. You would typically do this by creating an instance of ServiceInstanceListener. This class takes a factory function as it’s first parameter:

public ServiceInstanceListener(Func<StatelessServiceContext, ICommunicationListener> createCommunicationListener, string name = "");

So this factory function should create an instance of your listener.

My listener has a constructor with multiple dependencies. One of them is the StatelessServiceContext-instance provided in the factory function.

Is there a way of resolving a service where one of the dependencies is provided?

e.g. container.GetInstance<MyServiceListener>(context)

so that the container will use the provided services for any matching constructor parameter and resolve the rest from the container?

[vegar]

I haven’t had the time. Just close the case, though. I’ve received good input 😃

---

Fra: Bernhard Richter [e-mail] Sendt: fredag, september 14, 2018 8:16 pm Til: seesharper/LightInject Kopi: Vegar Vikan; Mention Emne: Re: [seesharper/LightInject] How to provide one of several constructor dependencies from a factory method? (#435)

@vegarhttps://github.com/vegar Did you manage to get this working?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/seesharper/LightInject/issues/435#issuecomment-421442124, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAuqZcQK6n50TfK3dp_UoSkhS8EajvJtks5ua_JigaJpZM4WBGbo.

[seesharper]

The general advice here is not to mix runtime data with services. In fact, this is probably one of the features I regret ever adding to LightInject. We are actually considering marking these register methods obsolete and remove them in the next major release. Instead of injecting runtime data, it is better to let this data flow through the methods exposed by the service.

In your case it would probably be better to inject some kind of IContextAccessor that provides the context. 👍

This topic is very well covered in this article by @dotnetjunkie

https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=99