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.
Related
I use the get_it package for the service locator. There are many types such as Singleton, Injectable, LazySingleton, etc.
Can you explain to me, what are their meanings? I try to do research for them, but I can not find nice information about the types that are above.
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.)
Previously I asked this question and on a answer I got this comment:
This works, however injecting the container to a part, as far as I know, is not a "normal" use-case of MEF.
In my web app I have a few repositories that, of course, retrieve entities from the DB. To make them as loosely coupled as possible I'm making them return interfaces (eg IUser, IBill, IBlaBlaBla...) and the repository project only references the library project (that contains the interfaces). I use MEF composition capabilities to tie it all up...
Since the repository must have a concrete object to fill with info it got from the DB and the only the Container is aware of which concrete class maps to a specific interface I think that the repository MUST have reference to the container so it can call the "Resolve()", get a new instance and do his job, but that apparently is a mistake.
Can anyone tell me why and what approach would be better?
PS: I don't know if it's relevant but I'm using DDD...
I think the flaw in your design that lead to this problem is the use of interfaces to hide entities behind. Since entities are your core concept in your domain, there should be no use in hiding them behind an abstraction. Let's put it differently: do you ever have a different implementation of IUser?
In other words, ditch the IUser, IBill, etc. interface and let your repositories and business commands depend directly on your aggregate entities.
I'm trying to design the architecture for a new LOB MVVM project utilising Caliburn Micro and nHibernate and am now at the point of looking into DI and IOC.
A lot of the examples for bootstrapping Caliburn Micro use MEF as the DI\IOC mechanism.
What I'm struggling with is that MEF seems to by reasonably popular but the idea of the Mef [Imports] annotations smells to me like another flavour of a Service Locator?
Am I missing something about MEF whereby almost all the examples I've seen are not using it correctly or have I completely not understood something about how it's used whereby it side steps the whole service locator issues?
MEF is not a Service Locator, on it's own. It can be used to implement a Service Locator (CompositionInitializer in the Silverlight version is effectively a Service Locator built into MEF), but it can also do dependency injection directly.
While the attributes may "smell" to you, they alone don't cause this to be a service locator, as you can use [ImportingConstructor] to inject data at creation time.
Note that the attributes are actually not the only way to use MEF - it can also work via direct registration or convention based registration instead (which is supported in the CodePlex drops and .NET 4.5).
I suppose if you were to just new up parts that had property imports and try to use them, then you could run into some of the same problems described here: Service Locator is an Anti-Pattern
But in practice you get your parts from the container, and if you use [Import] without the additional allowDefault property, then the part is required and the container will blow up on you if you ask for the part doing the import. It will blow up at runtime, yes, but unlike a run of the mill service-locator, its fairly straightforward to do static analysis of your MEF container using a test framework. I've written about it a couple times here and here.
It hasn't been a problem for me in practice, for a couple of reasons:
I get my parts from the container.
I use composition tests.
I'm writing applications, not framework code.
Is the provider pattern an implementation of IOC? If not, why not?
(reading through martin fowlers article on ioc)
In my opinion, yes the Provider pattern is a form of Inversion of Control.
What's my reasoning?
At it's core IoC is a very generic concept, so much so that Martin Fowler talks about reading user input from the command line as being a form of IoC.
With the Provider model the inversion happens when the provider framework decides which provider will be used when a given method is called. For example when you invoke Membership.GetUser your code is delegating control of which Membership provider to use, to the provider framework.
As Fowler says "Inversion of Control is a common characteristic of frameworks" and if you think about it many patterns are concerned with IoC (e.g Strategy pattern). I would go as far as to say that even polymophism is a form of IoC (a point I would happily like to hear a counter argument to).
Spring uses BeanFactory and its concrete implementations, most important of which is ApplicationContext. Don't know what Guice does.
I think even if it is, you shouldn't necessarily use it "instead of" IOC or you will be missing out and have a messy code base. IOC containers can generally be configured in code which can be more powerful and far easier to maintain, whereas the Provider Model must be configured in the Web.Config.
I am actually considering moving away from the Provider Model now that I am using an IOC container because it seems like overkill.
Read more on my blog post - hopefully the blog will get some good comments about it too:
http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html