-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to get/know the type of object for which the factory was called #76
Comments
The problem is that one object can be used as a dependency to create objects of different types. This depends, for example, on the lifetime. I made an example of how I would implement logging. |
I agree that this is a problem with an ambiguous solution, but in my opinion it can be solved by having each specific
The solution with creating additional types representing loggers for specific types certainly has a place to be, but it creates unnecessary verbosity and problems in cases where, for example, it is necessary to pass a non-default logger. Also, apparently, in this example there is a composition configuration error (it breaks off in mid-sentence) |
@Neakita could you please review this approach?
|
This is perfect for my case, however, the choice of name and the fact that the meaning depends on lifetime can be confusing, although I can't think of something more appropriate. Unless, judging by the name, the dependency is given to the object in ownership, which I would consider a bad approach, because then it should take responsibility for managing the lifetime of its dependencies, which it can only do if it creates them itself, although in this case it gets them from outside and the owner is considered a Composition that should manage their lifetime, there is an inconsistency here when the lifetime is, for example, transient. |
@Neakita Yes that's a reasonable point. Please see this option. |
As far as I understand, in this example you replaced It seems to me that the previous example providing the My point was that, as you said in your report on DotNext, Pure.DI is intentionally not responsible for the lifetime of dependencies of the Transient type implementing I have a suggestion about this that I would like to make separate issue later. In my opinion, something like I'm sorry if I'm confusing or distracting you. |
Yes, that's the way it is
The array option would be useful when we want to account for all consumers.
Right now it is possible to control transient
I haven't figured out how to use context to call a method with a generic type. |
Not a context, but marker type such as TT, TT1, etc, some brand new |
Not a logger case, maybe something other. I saw the generated code and it can actually be |
This is already implemented for some cases, e.g. see here. |
Yeah I get your idea, created a ticket and will think about it. |
Fixed in 2.1.42 |
Greetings!
I have a situation where I want to get an ILogger (from Serilog) dependency in a certain class:
Ideally, the default factory should provide a contextual logger, i.e. it should be obtained from the
Log.ForContext<T>()
orLog.ForContext(typeof(T))
method, so whenWriteableBitmapPool
is being created it should get logger instance from result of callingLog.ForContext<WriteableBitmapPool>()
method.Perhaps the API should look something like
where
TSomething
is replaced with something more suitableso that the generator can convert this to something like
Serilog.ILogger logger = Log.ForContext<WriteableBitmapPool>();
just before
WriteableBitmapPool
instance creationAlternatively add some
Type
property toIContext
so factory could look like.Bind<ILogger>().To(context => Log.ForContext(context.ObjType))
The text was updated successfully, but these errors were encountered: