I'm using SignalR in the application I am writing, but I'm confused by examples like the last example at https://github.com/SignalR/SignalR/wiki/Hubs in particular the use of AspNetHost.DependencyResolver
IConnectionManager connectionManager = AspNetHost.DependencyResolver.Resolve<IConnectionManager>();
dynamic clients = connectionManager.GetClients<MyHub>();
If I'm not mistaken this is a Dependency Injection tool? Problem is I'm using StructureMap for everything else, and I'd rather not have two dependency Injection frameworks.
Is AspNetHost.DependencyResolver necessary?
SignalR has a bunch of dependencies/services that it needs to function, and it gets those through a DependencyResolver.
You can replace that resolver with your own (e.g StructureMap, Ninject etc.), but if you don't, SignalR will use it's default resolver.
Related
I have an existing MVC app where I use Castle Windsor as IoC container. It runs in Azure as a Web App.
We have recently expanded the functionality with a new controller based on ASP.Net Web API.
The container is set up and configured in global.asax
But - due to the different nature of the MVC framework and the Web API framework, specifically how they handle HttpContext, we have some code at the core part of our code, that needs to work according to which controller method was executed. The code for doing this is seperated in two different classes (implementing the same interface).
The solution we have now is to configure the container with both instances, inject both instances to the class, and at runtime figure out (by investigating the HttpContext data) which to execute code on.
But I think that sucks.
Is there any way we can do this better? Can we instruct Castle Windsor to figure out which instance to inject at runtime - based on e.g. a value in the URI?
I'm replacing the service tier in an existing older Struts2 project with Spring service beans developed for another project.
I'd like to just #Inject these service beans into my Action classes.
Is it required to use Struts' Spring Plugin? Or can I add Spring into my Struts web application like I would any other (ContextLoaderListener, applicationContext.xml, context:component-scan)?
Am I missing some reason why the Struts Spring plugin helps me in another way?
Many thanks!
Well you can do the most of the things what you have described in your question as Services layer is completely out of view for the S2 and Struts2 do not care how you are creating your Service layer instances and other things.
Benefits i am seeing of using Struts2-Spring plugin is to delegate creation of Struts2 related things to Spring like Action classes creation,Interceptors,Results etc.
My Suggestion is to use the plugin as you are going to use the Spring in your application so its very good and flexible as well powerful to use the power of Spring DI to create required objects needed by S2 else S2 will use its own data creation factory to create framework component.
Why wouldn't you use the Spring plugin?
It's essentially invisible, uses Spring to create your actions (including injecting other Spring beans), etc.
Guice's #Inject doesn't know anything about Spring beans, AFAIK, so you'd be naming classes manually, they'd be instantiated via normal Java/Guice mechanisms, wouldn't be injected with their own Spring dependencies (unless you did it manually, or via AOP, or whatever).
You'd also need to use non-Spring mechanisms for doing injection in testing, which is fine, but unless you provide more details regarding your usecase, I don't really see a reason to bypass the functionality the Spring plugin provides out-of-the-box.
I'm using Autofac to implement IoC in my solution, But I am doubtful whether I'm doing it right or not. Here's the scenario:
I have some Manager classes which all derive from BaseManager class. The BaseManager has a protected User CurrentUser field. What I'm trying to do, is to resolve the CurrentUser using Autofac. I have written anIUserProvider interface and implemented a couple of classes (e.g. WebUserProvider and WinformsUserProvider).
Then I registered my provider as below (for example, in Global.asax):
builder.Register(c => new WebUserProvider(...)).As<IUserProvider>();
How can I resolve dependencies (access container in my classes)? I could use a singleton or a service locator pattern but seems like it's an anti-pattern. So how should I resolve my dependency?
This sounds like overengineering to me. Why would you have a base manager class that has knowledge of the user? Having a few manager classes is a code smell and a maintenance hazard on its own, as your are abstracting too much. Do you really need that?
How can I resolve dependencies (access container in my classes)?
You should not be looking for a way to access your container. Container must be initialized once, in a single place. You should inject all the dependencies via constructor. These dependencies are passed in from the root of the dependency graph using container.Resolve<T> and elsewhere in the dependency graph using constructor injection (or some folks use property injection).
After reading "Dependency Injection in .NET" by Mark Seemann I stay away from the Service Locator which is an anti-pattern.
Upon reading the release notes on MVC 4 I see:
Improved Inversion of Control (IoC) via DependencyResolver: Web API
now uses the service locator pattern implemented by MVC’s dependency
resolver to obtain instances for many different facilities.
Thus I'm left curious and confused why Microsoft would use a service locator in 2012.
That's an implementation detail that you shouldn't care about. The important thing is that now that the Web API uses the DependencyResolver to resolve dependencies for many different facilities, you will be able to use a real dependency injection whenever you want to plug into those facilities. So in your code you will be using a real dependency injection. If Microsoft didn't use the DependencyResolver then it would have been you that must have used it (as a service locator anti-pattern) in your code in order to resolve dependencies when you want to implement some custom functionality. This would have been bad for you. Now it's bad for Microsoft but you don't care about them.
Thus I'm left curious and confused why Microsoft would use a service locator in 2012.
Because designing a framework is not the same as designing an application using a framework. There are some different things to take into consideration when designing a reusable framework such as ASP.NET MVC rather than just what's written in the books. Some example is to design the framework in such a way that a person using this framework will be able to take advantage of the best practices written in the books in his code using this framework.
As Darin points out, ASP.NET MVC 4 is a Framework and is container agnostic. That's why it provides a service locator in the form of IDependencyResolver. This allows anyone to plug in their container of choice.
However, I wouldn't call this an anti pattern. This allows you to use the container of your choice, but it doesn't force you the application developer to use service location. If the framework forced the developer to use Service Location, then I would call it an anti-pattern. But the developer who builds an ASP.NET MVC application is free to use DI via constructor injection, property setup, or service location. It's their choice.
Look at all the ASP.NET MVC examples of dependency injection published by me or the ASP.NET MVC team. In pretty much all cases, they're using constructor injection. They're not using service location.
In fact, most of the ASP.NET MVC source code itself doesn't use service location to retrieve dependencies. There's a few key places where the MVC calls into the service locator for legacy APIs and such. But that's about it.
Firstly - I'm not asking this question How to host a web service in MVC3? I know where the button is :-)
I'm trying to find an example of best practices of how to use the new DI / Common Service Locator framework in order to make web service calls (and code dependent on web service calls) testable. I've no experience of using NInject or the like - is that the way to go?
Pretty much the same way one deals with any external depenency -- wrap it up in an interface, make the controller take an instance of the interface as a constructor parameter. Implementation-wise, you can handle things a number of ways, we have typically made the service wrapper take the service as a dependency and let structuremap worry about lifecycle. Not horribly familiar with NInject so I'm not sure if there is a better way there but I'd suspect they have similar capabilities.
I don't know what is the best practice but I think you can do this with Windsor's WCF facility (Ninject has a WCF extension as well). Register your service, then set your dependency resolver and let MVC's dependency resolver to do the hard work, constructor injection for example:
Register your service:
container = new WindsorContainer().AddFacility<WcfFacility>();
container.Register(Component
.For<IService>()
.On(WcfEndpoint.FromConfiguration("...")))
.LifeStyle.Transient);
Set dependency resolver:
DependencyResolver.SetResolver(new WindsorDependencyResolver(container));
Then MVC3's new dependency resolver should be able to inject your service proxy into the constructor, for example:
public HomeController(IService service)
{
// ...
}