I have a situation where I want to dependency inject my user object, but also place the current user in the IoC container. I want the following lines to work:
kernel.Get<User>(); // Should return a new User()
kernel.Get<User>("Current"); // Should return the current user
One might think bindings like this would work:
Bind<User>().ToSelf();
Bind<User>().ToMethod(LoadCurrentUser).InRequestScope().Named("Current");
Of course, that gives:
Ninject.ActivationException: Error activating User
More than one matching bindings are available.
Activation path:
1) Request for User
Suggestions:
1) Ensure that you have defined a binding for User only once.
I understand the error since a Named binding does not restrict the application of that binding, so both bindings apply. It seems clear that I need to use the contextual bind with the .When*() methods but I can't come up with any way to do that. I feel like there should be when methods that detect whether a named instance is applied. Something like:
// Not valid Ninject syntax
Bind<User>().ToSelf().WhenUnnamedRequested();
Bind<User>().ToMethod(LoadCurrentUser).WhenNamedRequested().InRequestScope().Named("Current");
I can't find any place on the IRequest interface or it's properties that tells me the name requested. How do I do this?
This question was answerd on the mailing list:
http://groups.google.com/group/ninject/browse_thread/thread/cd95847dc4dcfc9d?hl=en
If you are accessing the user by calling Get on the kernel (which I hope you do not) then give the first binding a name as well and access User always by name. Actually, there is a way to get an instance from the binding without a name. But because I heartily recommend not to do this, I do not show how to to this here. If you still want to do it this way I'll tell you later how this would work.
If you are doing it the better and prefered way and inject the user to the objects that require it as dependency there are two options:
The easier one: Give the first binding a name and add a named attribute to the parameters e.g. ctor([Named("NewUser") IUser newUser, [Named("Current")] IUser
currentUser)
Or the prefered way to keep the implementation classes free of the IoC framework: Specify custom attributes and add them to the parameters e.g. ctor([NewUser] IUser newUser, [CurrentUser]IUser currentUser). Change the Bindings to:
Bind<User>().ToSelf()
.WhenTargetHas<NewUserAttribute>();
Bind<User>().ToMethod(LoadCurrentUser)
.InRequestScope()
.WhenTargetHas<CurrentUserAttribute>();
Related
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 looking to find out how to use Ninject to get all instances that inherit from a base class that also pass some custom Boolean criteria. This is a continuation of a previous question. This is how I am creating a binging for all classes that inherit from MyAbstractClass.
_kernel.Bind(x => { x
.FromThisAssembly()
.SelectAllClasses()
.InheritedFrom<MyAbstractClass>()
.BindAllBaseClasses()
.Configure(syntax => syntax.InSingletonScope());
});
If I have the syntax correct, this will create a singleton scope binding for all classes that inherit from MyAbstractClass. Next I need to get/construct all the classes.
IEnumerable<MyAbstractClass> items = kernel.GetAll<MyAbstractClass>();
The code above will get/create all classes that inherit from MyAbstractClass.
Now I need to add one more step to this process. Based on “access roles” not all classes that inherit from MyAbstractClass should be created because the current user might not have access to functionality for every derived class. So I tried adding a CanLoad Boolean to each derived class and tried the following.
IEnumerable<MyAbstractClass> items = kernel.GetAll<MyAbstractClass>().Where(x => x.CanLoad == true);
While items did contain only the classes I expected, based on my CanLoad logic, I did see the constructor for each derived class being called because of the kernel.GetAll() method. Also it will have to create the class to call its CanLoad method, so that will not work. I thought about making the CanLoad static too. I also thought about a method that would look similar to the following.
public bool CanLoad<T>() where T : MyAbstractClass {
//return true if the current user has the correct access roles to create class of type T
}
So my question is how can I use the Ninject GetAll() method to get all classes that inherit from MyAbstractClass that also return true for the CanLoad Boolean method? I have been trying to use Ninject and Linq and possibly Reflection but I do not have a solution yet.
Edit:
To elaborate on the “permission logic”, at the very beginning our app calls out to a web service to get a list of LDAP groups/roles which are returned as a simple list of string. Each of the derived classes are actually ViewModels and each ViewModel “needs” a minimum role for its functionality to be usable by the current user. I thought I could tie the Ninject/binding/get logic with some custom “permission logic” and only bind/get classes the current user has access to. The list of VMs become an ItemsSource binding for a docking control (and we are considering using creating an ItemsSource binding for the Ribbon control as well). It’s all research at this point.
Add a When constraint to the binding:
.Configure(syntax => syntax
.When(... check permission here...)
.InSingletonScope());
Since you didn't say anything about the logic how you know whether the user has permission, i can't give you more specific information here. But generally speaking, you should add a 'When' constraint to your binding whenever you want to make sure it cannot and will not be instanciated unless a condition is met.
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.
Long post - sorry....
I'm doing input validation for a WCF service and using StructureMap IoC to instantiate the appropriate validation objects.
I have 2 different validation groups:
Per object validation: means that one input parameter, will be resolve by the Ioc (e.g. Ioc.ResolveAll<IValidatorObject<InputParameter1>, .... <InputParameter2>... etc). If any rules are found, the validate method is invoked.
Per context validation: mean that validation rules are invoked, based on the current context (explicit roles). A context could be 'deposit money' or 'open bank account'. Context validation are usually dependent on 2 or more of the input parameters and is the key difference between object and context validation.
The input validation is performed in the BeforeCall event call in the IParameterInspector (provider/server side!). With this event I get a string containing the operation name (aka. the context) and an object[] with the input parameters.
The problem is that there's multiple validation rules for a single context and the only way I have figured out to register the context in the Ioc, is by using named intances. However I can only register 1 named instance pr. interface. And the interface is not uniquely identifiable by its signature. E.g.
Context rule for 'create account': IValidatorContext<User, Account>
Context rule for 'deposit money': IValidatorContext<User, Account>
So my question is, whether it is possible to register the context in StructureMap in any other way than named instances - or maybe a way to group named instances.
An alternative route, is to implement explicit interfaces for each context, so that the DepositMoney service method might look like this:
public Response Deposit(IDepositMoney inputArguements)
where IDepositMoney contains the input parameters.
So am I way off here, or can I somehow register a context in StructureMap? Or should I just go ahead and use explicit interface instead (3rd option?)
Thanks in advance
Ended up wrapping each set of input parameters in a context and used the context to register in StructureMap. Works like a charm!
The whole idea of named instances is that the name points to a single instance, so you won't be able to use that feature to do what you are trying to achieve. I would use explicit interfaces, since this will allow you to auto wire more things and have less calls to your container.
I'm trying to embrace widespread dependency injection/IoC. As I read more and more about the benefits I can certainly appreciate them, however I am concerned that in some cases that embracing the dependency injection pattern might lead me to create flexibility at the expense of being able to limit risk by encapsulating controls on what the system is capable of doing and what mistakes I or another programmer on the project are capable of making. I suspect I'm missing something in the pattern that addresses my concerns and am hoping someone can point it out.
Here's a simplified example of what concerns me. Suppose I have a method NotifyAdmins on a Notification class and that I use this method to distribute very sensitive information to users that have been defined as administrators in the application. The information might be distributed by fax, email, IM, etc. based on user-defined settings. This method needs to retrieve a list of administrators. Historically, I would encapsulate building the set of administrators in the method with a call to an AdminSet class, or a call to a UserSet class that asks for a set of user objects that are administrators, or even via direct call(s) to the database. Then, I can call the method Notification.NotifyAdmins without fear of accidentally sending sensitive information to non-administrators.
I believe dependency injection calls for me to take an admin list as a parameter (in one form or another). This does facilitate testing, however, what's to prevent me from making a foolish mistake in calling code and passing in a set of NonAdmins? If I don't inject the set, I can only accidentally email the wrong people with mistakes in one or two fixed places. If I do inject the set aren't I exposed to making this mistake everywhere I call the method and inject the set of administrators? Am I doing something wrong? Are there facilities in the IoC frameworks that allow you to specify these kinds of constraints but still use dependency injection?
Thanks.
You need to reverse your thinking.
If you have a service/class that is supposed to mail out private information to admins only, instead of passing a list of admins to this service, instead you pass another service from which the class can retrieve the list of admins.
Yes, you still have the possibility of making a mistake, but this code:
AdminProvider provider = new AdminProvider();
Notification notify = new Notification(provider);
notify.Execute();
is harder to get wrong than this:
String[] admins = new String[] { "joenormal#hotmail.com" };
Notification notify = new Notification(admins);
notify.Execute();
In the first case, the methods and classes involved would clearly be named in such a way that it would be easy to spot a mistake.
Internally in your Execute method, the code might look like this:
List<String> admins = _AdminProvider.GetAdmins();
...
If, for some reason, the code looks like this:
List<String> admins = _AdminProvider.GetAllUserEmails();
then you have a problem, but that should be easy to spot.
No, dependency injection does not require you to pass the admin list as a parameter. I think you are slightly misunderstanding it. However, in your example, it would involve you injecting the AdminSet instance that your Notification class uses to build its admin list. This would then enable you to mock out this object to test the Notification class in isolation.
Dependencies are generally injected at the time a class is instantiated, using one of these methods: constructor injection (passing dependent class instances in the class's constructor), property injecion (setting the dependent class instances as properties) or something else (e.g. making all injectable objects implement a particular interface that allows the IOC container to call a single method that injects its dependencies. They are not generally injected into each method call as you suggest.
Other good answers have already been given, but I'd like to add this:
You can be both open for extensibility (following the Open/Closed Principle) and still protect sensitive assets. One good way is by using the Specification pattern.
In this case, you could pass in a completely arbitrary list of users, but then filter those users by an AdminSpecification so that only Administrators recieve the notification.
Perhaps your Notification class would have an API similar to this:
public class Notification
{
private readonly string message;
public Notification(string message)
{
this.message = message;
this.AdminSpecification = new AdminSpecification();
}
public ISpecification AdminSpecification { get; set; }
public void SendTo(IEnumerable users)
{
foreach(var u in users.Where(this.AdminSpecification.IsSatisfiedBy))
{
this.Notify(u);
}
}
// more members
}
You can still override the filtering behavior for testing-purposes by assigning a differet Specification, but the default value is secure, so you would be less likely to make mistakes with this API.
For even better protection, you could wrap this whole implementation behind a Facade interface.