I would like to use Autofac IOC container in my bot application (based on BotFramework).
I can see that framework itself already uses it.
But I can't figure out how to do it gracefully... I don't want to resolve my components on every post invocation (it will slow down my post method execution).
I appreciate if you share code snippets with your solutions.
Thanks in advance!
You can use the Autofac container being used in the framework in the Global.asax and perform your own registrations.
The key code pieces are:
var builder = new ContainerBuilder();
// perform your registrations on the builder
// update the container being used by the framework
builder.Update(Conversation.Container);
For a real implementation of this, you could take a look to the ContosoFlowers sample where you will see that a Module is used to register the application specific components. Here is the Global.asax and here the actual module.
Related
I'm trying to create a service such that once it is created it only allows itself to be held by a single consumer/bundle at any one time. (If this is against the philosophy/specification of OSGi then that obviously provides a quick answer but reference to the OSGi specs. stating this would be appreciated.)
To implement such a requirement I implemented the ServiceFactory interface thinking that whenever there was a requirement for the service the getService(Bundle bundle, ServiceRegistration<S> registration) method would be called and it would be where I could determine if the Bundle was a new consumer or not and act accordingly.
It appears that this is not the case in the scenario I have tested this in.
Using a Apache Karaf and instantiating a consumer of the Service via Blueprint it would seem that the getService method is never called. Instead the consumer's binding method for the service is called directly but injecting a proxy service object.
While I understand that Blueprint uses proxies surely there is still the obligation of the ServiceFactory contract to fulfil even if it's a proxy object consuming the service?
Why do I want to do this?
I am attempting to wrap JavaFX and the Stage class and because JavaFX isn't OSGi friendly I am attempting to co-ordinate access to the Stage object. I'm aware that there are frameworks such as Drombler but a brief look at them made me think that it doesn't suit my use case. They appear too restrictive for my needs e.g. I don't necessarily wish to layout an application in the manner Drombler uses.
It depends what you mean by a consumer. ServiceFactory does give you the chance to create a separate instance of a service per bundle that calls getService on your service. It's not clear from your question but I suspect you weren't seeing the getService invoked multiple times because you were fetching the service from the same consumer bundle. In this case, ServiceFactory simply returns the same object repeatedly.
As for your general question about restricting access to a single consumer, no that really goes against the OSGi philosophy. I'm sorry I don't have a spec reference for you but the clue is in the name: it's a service that is available to all.
I'm aware that there are frameworks such as Drombler but a brief look at them made me think that it doesn't suit my use case. They appear too restrictive for my needs e.g. I don't necessarily wish to layout an application in the manner Drombler uses.
Please note that the layout of Drombler FX applications is pluggable so you can provide your own implementation tailored to your needs. This allows you to get the most out of Drombler FX and JavaFX.
While this feature is available for some time, there is now a new tutorial trail explaining it in more detail.
I'm using AutoMappper 5.2 in my MVC project. I have made use of IMapper creating profiles which I understand profiles are a way to organise mappings. I am injecting IMapper into my controllers using Simple Injector to register an instance.
What I would like to know is can you use them in a way where you only retrieve/set up the profile you need for a specific controller? If so, how would you go about that? If you have to add all the profiles into one mapping configuration object does that have a performance impact or is it marginal?
I cannot find any resources or questions that deals with using a specific type of profile, they only deal with creating and registering them.
I think my answer to a similar question might help you. It is the last answer here: How to register AutoMapper 4.2.0 with Simple Injector.
It's basically what Steven said.. you need to create a generic profile wrapper that implements the IMapper interface, with the generic argument being a specific profile. This allows you to create any number of profiles, batch-register them all, and to inject only the one that you need in your controller:
ProfileMapper<ApplicationProfile> appProfileMapper;
ProfileMapper<MvcProfile> mvcProfileMapper;
ProfileMapper<GuestProfile> guestProfile;
In almost every tutorial I've seen on using ngResource in Angular JS I see them set up the $resource as part of a factory. My question is can this also be set up as a service as well that could be injected into the controller? I just wanted to clarify that before I start writing any code on it. Thanks!
I'm on an MVC3 project and I am using snap structuremap for my dependecy injection. Everything was in-place, except when I started using SignalR where I can't seem to implement my DI like I have on my controllers. I've been googling about implementing structuremap DI on SignalR for days now, but haven't found a strong sample on how to do this. Seems like everyone that are using SignalR are using Ninject.
My goal is to have conditional statements (which requires me to inject services) inside my Hub before calling my client methods, but I had no success on this.
I didn't want this thing to delay my development so I researched for alternative ways, then I found out that I can actually call my client methods from my controllers using the following codes:
IConnectionManager connectionManager = AspNetHost.DependencyResolver.Resolve<IConnectionManager>();
dynamic clients = connectionManager.GetClients<MyHub>();
clients.myClientScript();
This works for me, but I'm not sure if this is a good approach - especially that I am using dependency injection.
So my question is: Is it ok to keep calling this inside my controller? Do you have a better approach?
Thanks
There is no reason you cannot send information to connected clients from your controller using SignalR however the current client will not see this information (due to not being connected during a post).
That said, getting Structuremap into SignalR is actually pretty easy. You can see exactly how to accomplish this in my answer here: https://stackoverflow.com/a/9866374/701062.
I have seen this line of code in several tutorials for using Unity in asp.net mvc3. I was under the impression that Service Locator is an anti-pattern and not best practice. Is this Service Locator something other than the anti-pattern defined, or is this line of code / this implementation considered bad practice.
ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(Container));
Old question, but for the benefit of others:
While I absolutely agree with the mantra "Service Location is an anti-pattern", there are definitely exceptions to that rule.
When you use Dependency Injection (like Unity) then, yes, certainly don't use ServiceLocator and only use constructor injection for all your service classes. (Also don't use "new" for anything other than value objects like DTOs.)
However, there are cases where you simply can't use constructor injection and then the only way to get access to a service is to use a workaround to access your Unity container directly, and in such cases, ServiceLocator is a good standard way to accomplish that. This is the case when the class isn't instantiated by you (or more specifically, it isn't instantiated by Unity) but by the .NET framework for example.
A few simple examples of where ServiceLocator might be useful, is to get access to services registered in your Unity container from:
an implementation of a WCF IEndpointBehavior or IClientMessageInspector
an implementation of a WPF IValueConverter
or you may not necessarily even want to get access to "services" from the class, but you simply want to write code that is unit-testable, but for some reason the class can't be instatiated at all (or not easily) because it would normally be constructed by the .NET Framework, so you extract your custom code into a class that is testable, and resolve it in the non-testable class using the ServiceLocator.
Note that this line is not ideal:
ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(Container));
The ServiceLocator.Current property is going to execute the delegate provided every time you access Current, i.e. a new UnityServiceLocator is going to get created every time. Instead, you probably want to do this:
IServiceLocator locator = new UnityServiceLocator(container);
ServiceLocator.SetLocatorProvider(() => locator);
If you create a framework which is designed to be container agnostic the service locator (although it should be a No-Go in an application) is an additional layer of indirection that allows you to swap out Unity for something different. In addition the use of the service locator does not enforce the use of DI for applications that use that framework.
It is the same anti-patten that people talk about. All that line is doing is setting the service locator provider to be an instance of UnityServiceLocator, i.e. to use the Unity implementation of the ISerivceLocator. Optionally if you would like you can have your own implementation is IServiceLocator and use that instead of UnityServiceLocator.
Using Service Locator is considered a bad practice for various reasons as listed here