Using Ninject 2 MVC 3. Correct me if i am wrong but ive seen two way of using Ninject in an MVC 3 application. We can use a new controller factory which is like ControllerBuilder.Current.SetControllerFactory(new NinjectControllerFactory()); or using NinjectHttpApplication and then configure the kernel.
I was wondering what difference between use of a controller factory and NinjectHttpApplication to configure the binding for DI?
And what are the best place to setup DI ?
NinjectHttpApplication calls ControllerBuilder.Current.SetControllerFactory(new NinjectControllerFactory()) internally.
But additionally it sets up various bindings and provides many new features. In other words it's less work and adds new features. Best you read my blog post about the MVC3 extension. http://www.planetgeek.ch/2010/11/13/official-ninject-mvc-extension-gets-support-for-mvc3/
Related
I had a webapi in which I was using app.CreatePerOwinContext in startup.cs file but I want to migrate that webapi to .net core 2.1. So I have stuck at this point as I can't fine any alternate for CreatePerOwinContext.
Here is my webapi code:
public static UserManager<IdentityUser> Create(IdentityFactoryOptions<UserManager<IdentityUser>> options, IOwinContext context)
{
var manager = new UserManager<IdentityUser>(new UserStore());
return manager;
}
public void ConfigureAuth(IAppBuilder app)
{
app.CreatePerOwinContext<UserManager<IdentityUser>>(Create);
...
}
So how can I convert the above code in .net core 2.1?
That method was used as a service locator to load up dependencies and then access them throughout your code. Service location on its own is considered an anti-pattern, and is not recommended for use in the vast majority of real world situations.
Instead, people use IOC containers now to manage their dependency injection. In ASP.NET MVC Core, there's now a lightweight and "good enough" IOC container provided for you as part of the framework.
Microsoft provides an overview in this article, but the short version is that in your Startup.cs you register your dependency tree under ConfigureServices (usually using an extension method so Startup.cs doesn't get too large).
After you've registered your dependencies, you load them either through property injection, constructor injection, or method parameter injection. This results in cleaner code that is more maintainable than standard service location.
Edit:
If you truly insist on managing a service locator either because the technical debt is acceptable or because the business case warrants the current design, then I suggest you transition your work from OwinContext over to HttpContext.
In ASP.NET Core, you access the HttpContext by injecting the HttpContextAccessor into your class, and changing your OwinContext calls to pull from the key value store in HttpContext.
Instructions for injecting HttpContextAccessor can be found in this SO answer. Simply store KVPs using HttpContext.Current.Application["myObject"].
I don't recommend doing this, but I'm willing to share it because I understand the reality of deadlines vs the idealism of architecture.
I've decided to use custom template engine with Spring MVC framework.
my templates implemented in java and have method for rendering into String:
public String render(Map context);
how to configure spring to make them available in Controller beans as views, for example like:
ModelAndView modelAndView = new ModelAndView("activationPage"); // - view name which will actually be java class name reference.
modelAndView.addObject("validationResult", validationResult);
return modelAndView;
Model will be passed as context in code connecting spring and my template engine.
You need to implement org.springframework.web.servlet.View (which should be easy, you already have something very similar to the render method it needs), as well as org.springframework.web.servlet.ViewResolver, which maps the view names (e.g. "activationPage") on your custom views.
Once you have that, drop a bean of your ViewResolver class into the context, and (unless you've done something else that gets in the way) it should automatically be picked up by Spring and should just work. if you have other ViewResolvers already in there, they may get into a fight over who gets to resolve the view, in which case ask a new question.
Hi I am the author of Rythm template engine, about half year ago I am having the same requirement like you. What I did is to read the source code of Velocity and Freemarker view of SpringFramework. And then create the Rythm view for spring following their approach.
It's easy to follow something that is already there, and it makes your implementation in good quality to follow the official module. Good luck on you :-)
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Inject repository to custom membership provider with Ninject
I have searched much about this topic too much the most close answer was here
MVC 3 ninject custom membership context disposed error
but I don't have any idea about the details all I have in my application is a domain contains my entities and abstraction for repositories and the implementation everything works fine when I use my Ninject binding like this
public class NinjectControllerFactory : DefaultControllerFactory{
readonly IKernel _kernel;
public NinjectControllerFactory(){
_kernel=new StandardKernel();
AddBindings();
}
protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType){
return controllerType == null
? null
: (IController) _kernel.Get(controllerType);
}
void AddBindings(){
_kernel.Bind<IŁSomeRepository>()
.To<EFSomeRepository>();
but I have no idea how to bind the customer membership provider I have read about this that I have to inject via a poperty but I don't know how, any ideas ?
First, you should be using Ninject.MVC3 rather than your own controller factory. Ninject.MVC3 takes care of hooking everything up, you just need to provide your mappings in App_Start\NinjectWebCommon.cs
Second, don't bother with using Ninject for Membership, unless you're using a custom membership provider. Even then, it's a lot less of a pain if you don't mix Ninject and Membership. I would suggest not bothering with it unless you really know what you're doing.
The problem is that Membership is a static class, that creates a static instance of the Membership Provider. This means it doesn't get destroyed at the end of the request. There are ways around this, but in general, it's just a lot easier to use Membership as-is than try to make it work with DI.
The question you linked to solves a specific problem, relating to injecting business logic into your custom membership provider. If you need to do this, then it might be a good choice. However, I find that most custom membership providers tend to be very simple.
The tutorial by the msdn (source) recommends using an IDependencyResolver:
IDependencyResolver resolver = DependencyResolver.Current;
IDependencyResolver newResolver = new UnityDependencyResolver(container, resolver);
DependencyResolver.SetResolver(newResolver);
I was under the impression that IDependencyResolver does not properly manage object lifetime because it lacks a release method, and also that is conceptually a service locator anti-pattern (source).
How could I refactor this tutorial to not use IDependencyResolver?
Use Unity.Mvc3, there is a HierarchicalLifetimeManager that can manage lifetime for objects implementing IDispoable.
Its not an anti pattern if you resolve only at the composition root here, which basically with MVC is via constructor injection in the controller.
http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx
Note this doesn't have to be a custom controller factory you create, unity will inject automatically for you. See my code here:
http://completedevelopment.blogspot.com/2011/12/using-dependency-injection-with-mvc.html
Is it possible to inject dependencies into an MVC ViewPage (must support layout pages) without using DependencyResolver?
I would rather not use DependencyResolver at all (I had major problems when injecting NH sessions into ActionFilters in the past (leaking all over the place)). However, I'm not sure if there is an alternative?
The other complexity I have is that the DependencyResolver needs to be tenant aware (each tenant has its own (StructureMap) container). I'm currently doing this by passing in a lazy instance of my tenant container resolver (seems this is necessary otherwise the resolver is cached):
public SmDependencyResolver(Func<ISiteContainerResolver> containerResolver)
{
this.containerResolver = containerResolver;
}
public object GetService(Type serviceType)
{
var container = containerResolver().Resolve();
If I end up using DependencyResolver should I ditch my StructureMap controller factory since it looks like DependencyResolver handles this too?
Thanks
Ben
Given that the DependencyResolver is used by so many aspects of the ASP.NET MVC framework for dependency injection your life will be easier if you use it - as you say it means you don't need your own versions of things like the controller factory.
That said, the framework is very flexible and it is always open for you to plug in your own version of things - I just prefer to create as little of my own code as possible on the KISS principle.