Is it possible for Autofac modules to declare registrations that it depends on?
It would be nice of Autofac could validate that these dependencies are fulfilled before a further runtime error.
The idea comes from one of Java's dependency injection framework, Guice which has a requireBinding function within its modules.
Autofac modules do not support the ability to declare their "requirements". Given the flexible nature of Autofac with the ability to provide dynamic registration sources and such, providing a function like requireBinding would require quite a bit of change to the internals of Autofac. (It is for this same reason that Autofac can't analyze potential object resolution failures at runtime without actually resolving the objects in question.)
Related
in my opinion, the get_it package is one of ways to dependency injection in flutter, is that so? I'm just not sure about it, please help me figure it out
Rather not. get_it describes itself as a Service Locator, as can be seen it its documentation. A service locator is a different pattern than Dependency Injection, although they can be used for the same purpose.
Both approaches aim towards abstracting object interfaces from their actual implementation, but do it in slightly different ways. In classical dependency injection (e.g. via constructor or interface injection), each object holds a reference to the objects that implements its specific behavior. With the service locator pattern, there is just one single object - getIt() in our case - that can be used to find implementations across the whole application.
A great and more extensive discussion of these appraoches can be found in this article by Martin Fowler.
I am a newcomer to C# / .Net / Prism / WPF / DevExpress and started to work on a big project in my company. As I am starting a bit late in the project, a lot of code was already produced and I stumble upon code like this very often:
public class AboutWindowViewModel : BindableBase
{
public AboutWindowViewModel(IUnityContainer container)
{
...
What I find "special" here is the dependence of the view model in the container. In the codebase I am currently looking at, it seems to be the "pattern". Every class gets a dependence in the IUnityContainer and then the dependencies are resolved manually with e.g.
container.ResolveEx<...>(...);
I am used to work with DI frameworks in other languages, so that example was just a non-sense to me because it goes against the definition of a DI framework and the problems it is meant to solve. For example, I tried to make up some code to test one of those view models and it turned out to be a nightmare.
Now, I addressed that concern to the developpers of my company and they answered me the following:
Prism recommendation is to resolve services using containers as they are needed.
Therefore, they resolve them all the time with the IUnityContainer.ResolveEx method.
My question is: is that really the recommended way to build up software with Prism??? If not, do you know where I can find documentation that clearly addresses that point with examples?
is that really the recommended way to build up software with Prism???
Not at all, in it's an anti-pattern.
Prism recommendation is to resolve services using containers as they are needed.
Not really just Prism, but more generally, the recommendation is to let the container resolve the dependencies. Of course, this can be done by calling Resolve manually, but in doing that one defeats all the benefits expected from dependency injection.
Rather, you want to list the dependencies as constructor parameters and let the container fill them. Your code does not need to depend on the container, except for the very entry-point ("resolution root"). The application should only ever contain a single Resolve statement that resolves the first instance.
Here's where Prism comes into play: in your PrismApplication.RegisterTypes and IModule.RegisterTypes, you configure your container. You tell it which type should implement which interface. Later on, when view models are needed, Prism (the ViewModelLocator to be precise) uses the container to resolve the view models, thereby resolving all the dependencies. There's no reason to make any class depend on the container, in fact, Prism doesn't register anything for IContainerRegistry in the first place.
Keep in mind that the container can not only inject singleton services, but also transient instances or factories. And if you need parametrized factories, you can always manually create and register complex factories.
On a side-note, I, personally, would be hesitant to work for a client with a code-base like this, as it's an obvious proof that their developers have no idea what they're doing.
We use Autofac for our API projects. Porting out functions over has been on our todo list since Azure Functions announced support for Autofac. We already share a lot of services / repositories, but currently new() them up in the function body, which is a bit verbose.
I took a swing at it today, but am finding that I'm just being more verbose elsewhere. Specifically, I realised that I was writing a lot of code to replicate the functionality offered by bindings.
As an example, take the [CosmosDB()] binding attribute, which basically gives one a working, authenticated ("read-to-eat") DocumentClient in a single line.
When I'm using Autofac, it's necessary to manually read several settings from the config and to initialise a KeyVault client, etc...
Can I have my cake and eat it? Is there some way to register dependencies from my bindings so that they are available for Autofac to supply to my services etc.?
For Functions created in Azure Functions V2, you should be able to register your dependencies via dependency injection. Here's a blog post on how to do this for Autofac: http://dontcodetired.com/blog/post/Azure-Functions-Dependency-Injection-with-Autofac
After migrating from PlayFramework version 2.4 to version 2.5, I need to inject dependencies.
I'm avoiding to use #Inject for constructor DI as in this the caller class of the class that has #Inject also needs to get the same dependencies injected to call the callee's constructor. This increases code complexity.
Please suggest any other way of DI which does not involve injecting to constructor.
MacWire looks like a great tool for constructor injection. It is macro-based and thus typesafe and non invasive. The README page has a very good documentation, definitely worth a look IMHO.
Apologies for the vague question, but how is dependency injection typically handled in a multi-project environment? Each module should be able to define its own dependencies and ideally they would be using the same dependency "container".
In the past, in a single project environment, I went about creating a dependency object container where I defined my implicits and then just imported then when I needed a dependency.
Any pointers or tips to point me in the right direction would be helpful.
This will have to be a bit vague since you don't say anything about what you're using to do your dependency injection, but FWIW, we have a current multi-project mixed scala/java environment injected with guice, so maybe this will be helpful to you.
Since guice allows you to include modules (i.e. nest one module inside another) this allows for hierarchical module structure (they must assume people will use it like this - there's even a grapher included with the distribution to make a nice picture of the relationship between your modules). So, for example, you might have a module that includes database connections and various objects that interact directly with that, and you'd then include that module directly with anything that interacts with the db layer.