I have the following bindings declared
Bind<IDataSource>().To<DataSourceOne>();
Bind<ISettings>().To<DataSourceSettings>
.WhenInjectedInto<DataSourceOne>();
Bind<ISettings>().To<Settings>();
now I call
Kernel.Get<IDataSourc>();
Ninject correctly injects a DataSourceSettings, but I need to pass a constructor argument to Settings and DataSourceSettings based on data from a config file. so I've changed the IDataSouce binding as follows
Kernel.Bind<IDataSource>().To<DataSourceOne>()
.WithConstructorArgument("settings", Kernel.Get<ISettings>(
new ConstructorArgument("data", objectContainingConfigFileData)
)
);
in that case Ninject injects Settings class instead of DataSourceSettings class. I assume the problem is that the ISettings is getting resolved before it is injected into the DataSourceSettings class so Ninject does not use the binding I intended it to. Is there a way to get around this. I haven't found anything yet.
It should work if you define the constructor argument for the ISettings binding and not for the DataSource binding. Assuming you already know the object with the config file data in the module. Otherwise maybe a factory would be more appropriate.
kernel.Bind<IDataSource>().To<DataSourceOne>();
kernel.Bind<ISettings>().To<DataSourceSettings>()
.WhenInjectedInto<DataSourceOne>()
.WithConstructorArgument("data", objectContainingConfigFileData);
kernel.Bind<ISettings>().To<Settings>();
Related
This kotlin data class is part of an internal library used in some Quarkus microservices (Quarkus 2.0.0.Final):
#ApplicationScoped
data class FooConfiguration(
#ConfigProperty(name = "foo.bar")
val fooBar: String
)
The library is used in a few microservices, and most of them do use that configuration. But some are not. For those, the foo.bar property is not defined in the application.properties. I would expect this to not matter at all, as those services are never injecting a FooConfiguration, so I'd expect that to never be constructed.
However, the application refuses startup with this error message:
SRCFG00014: The config property foo.bar is required but it could not be found in any config source
I know how to workaround this issue (simply supplying a nonsense value), but I currently wonder why this is an issue in the first place. The configuration bean should never get constructed. Why is this happening?
This is a MicroProfile Config-related issue.
Your foo.bar property is optional, not required, in the parlance of the MicroProfile Config specification, because a value for it is not present in any configuration source, as you have indicated. To inject a value for an optional MicroProfile Config configuration property, you need to use java.util.Optional. I don't know Kotlin, so here is what it would look like in Java:
#Inject
#ConfigProperty(name = "foo.bar")
private Optional<String> fooBar;
A similar question has been answered here:
How can I pass a runtime parameter as part of the dependency resolution?
However, I was wondering how this can be done when registering a generic class?
Normally, I would register it as following:
services.AddScoped(typeof(ITest<>), typeof(Test<>));
But what if I want to pass a runtime parameter to constructor? Without using DI, it would be something like:
new Test<MyClass>(string mystring, int myInt)
In the linked answer it's suggests using a factory method but this is giving me an error if I don't pass it the exact type.
The alternative would be to get an instance without passing a runtime parameter in the constructor and instead using a setter method after getting exact instance. I would like to avoid this however because every time after getting instance you must remember to call setter method.
Is there some way around it? I guess I could use some factory class instead of registering it in startup class...
EDIT:
After reading Steven's answer which was very useful, I updated question with more concrete example:
Following example is inside some method:
//instance of repository are passed inside constructor of class
//calling some to update/insert
//IMPORTANT - calling external service I want save parameters to db no matter what
using(var ctx=new DbContext())
{
//create log object
ctx.logs.add(Obj)
ctx.save()
}
//some code after
Let's say I want to be consistent and call method of my loggingrepository and there add logging object and save everything to database
However, every repository in constructor accepts DbContext, which is registered as scoped (durig one request).
If it's inside transaction, saving depends about code after calling external service and it can throw exception and save nothing.
So yeah, I could create new dbContext and pass it in logging method or call some private logging function and save inside it,
but point is that if I would ask for instance of loggingRepository I would want DI to pass this localy created dbContext variable to constructor
and not one registered as scoped inside startup method, so that addind and saving log happens no matter what external service or code after calling it does.
My situation in something similar, but it's going for some data in db based on current user and I don't wanna pass same parameter to numerous method, but only inside class constructor.
The general solution in injecting primitive configuration values into your application components, is to extract them into a Parameter Object. This gives those values a new, unambiguous type, which can be registered into your container:
// Parameter Object
public TestConfiguration
{
public string Mystring;
public int MyInt;
}
// (Generic) class using the Parameter Object
public class Test<T>
{
public Test(TestConfiguration config) { ... }
}
// Registering both
services.AddScoped(typeof(ITest<>), typeof(Test<>));
services.AddSingleton(new TestConfiguration { Mystring = ..., Myint = ... });
Configuration values are not considered to be runtime data as their values are known at startup and constant for the duration of the application. That's why you can supply them to the constructors of your application components.
Real runtime data, however, should not be passed on to a component during construction. Runtime data are values that are not known at startup and typically passed along by the user through a web request, are retrieved from the database, session, or anything that can change during the lifetime of the application.
Instead of passing runtime data in through the constructor, you should either:
Pass runtime data through method calls of the API or
Retrieve runtime data from specific abstractions that allow resolving runtime data.
You can find more information about passing runtime data here.
So, I have a viewmodel class in a xamarin project that I inject some dependencies into via ninject binding on app start. One of these is an IDialogService.
When my MainPage in my application changes it raises a property changed event and I rebind the implementation of the dialog service since it is tied to the MainPage.
If my viewmodel has already been created with lets say DialogServiceA and then when MainPage changes we rebind to DialogServiceB, will my viewmodel be using service A or B? I think it is using A and therefore does not display in the UI because it is tied to a MainPage that no longer exists.
So, if this is the case how can I dynamically change my dialog service but then update classes that have already been instantiated without changing everything to get the current dialog service from the container every time its used (therefore not injecting it at all really, and doing more of a servicelocator)
Also, if this approach is completely wrong, set me straight.
You're right. Re-configuration of the container does not affect already instanciated objects.
If you want to change dependencies without re-instanciating the dependent (parent ViewModel) there's a few possibilities for you:
use a factory to instanciate the service every time. Implement an Abstract Factory (Site by Mark Seeman) or use Ninject.Extensions.Factory to do so
instead of injecting a service directly, inject an adapter. The adapter then redirects the request to the currently appropriate service. To do so, either all service can be injected into the adapter, or you can use a factory as with the possibility above.
instead of inject a service directly, inject a proxy. The proxy is quite similar to the adapter, but instead of coding every method / property redirection specifically, you code a generic redirect by an interceptor. Here's a tutorial on castle dynamic proxy
At the end of the day, however, i believe you'll also need a way to manage when to change the service / which it should be. There's probably a design alternative which doesn't rely on exchanging objects in such a manner.. which would make it an easier (and thus better?) design.
Edit: i just saw that you also tagged the question as xamarin-forms. In that case it most likely won't be an option to use either a dynamic proxy nor ninject.extensions.factory (it relies on dynamic proxies, too). Why? dynamic proxy / IL emitting is not supported on all platforms, AFAIR specifically on Apple devices this can't be done.
I am using the NamedScoped Ninject extension in an attempt to create object graphs that are constructed everytime a command handler is constructed by the container. In other words, I want a fresh object graph for every command that might get processed by its corresponding handler.
I have used the .DefinesNamedScope("TopLevelOrhcestrator") binding when registering my "command handlers" as they are the top level for command processing.
A type in this named scope needs to be injected with the result of a method call on a type already registered in this named scope. I thought the best way to do this would be with a ninject provider.
Inside the provider I attempt to resolve the type in hopes I can call a method on it to pass into another object I am creating within this named scope. The problem I'm having is that when I ask the IContext for the instance inside the customer provider I get an exception that says "No matching scopes are available, and the type is declared InNamedScope(TopLevelOrchestrator).
context.Kernel.Get<TypeAlreadyRegisteredInScope>().MethodThatGetsAnotherDependency()
Is it possible to get types from the container inside a Ninject provider when they are registered inside a named scope?
EDIT
I apologize if the use case seems a bit odd, I am experimenting with some ideas about how to manage my units of work and other services/managers that may need a handle to the uow to complete a business usecase. I know its common for the unit of work to be "started" and then passed into all dependencies that may need to take part in a larger process. I was thinking I'd rather let my orchestrator take a unit of work factory so that it could deterministically destroy the UOW and it would be clear who the owner of a usecase is. What would get supplied to the managers/services would be a proxy to the unit of work that would be null until a real unit of work was started by the orchestrator. That's why I was attempting to link the proxy from the already registered type in my provider. This is all very experimental at this point and was testing some ideas.
I'd be happy to hear any further thoughts.
For MethodThatGetsAnotherDependency() to be able to .Get<>() an instance that is bound .InNamedScope(...) you will need to add the Context Preservation Extension.
This is because NamedScope is adding a parameter to the request context of the binding that has .DefinesNamedScope(...). As soon as that request is over, that context and it's parameters are forgotten. Now with the ContextPreservation extension the context is kept and reused for late / factory creations (Func<>, interface factory with .ToFactory() binding...). It think it should also work with providers.
If not, just switch to a factory instead of a provider.
However i have to admit that i don't fully understand why/what you are trying to achieve. There might be simpler ways.
Ninject now enables property injection into ValidationAttribute (https://github.com/ninject/ninject.web.mvc/wiki/Injection-of-validators). It works great, UNTIL you use bind the object InRequestScope().
So, here is what I think is happening. ValidationAttribute are implemented as singletons in ASP.NET.
The first time an attribute is instantiated, Ninject properly populates the injected property.
The object that was injected is disposed when the current request ends
Upon the next request, accessing the injected property throws an error because it has been disposed.
Ninject does not try to populate the injected property because the validation attribute is never re-instantiated.
Does this make sense? Does anyone have any idea for a work around?
That is correct.
If you really need a dependency in request scope then you have to inject a factory for the dependency instead of the dependency itself and use it to get a new instance during evaluation.