I am trying to figure out how to get runtime parameters setting using IOC setup in MVC4.
I have not selected an IOC framework yet and am happy to take suggestions. I would prefer to avoid NInject, as I have heard that it is fairly slow.
I need to specify my IOC After login. So I am thinking that I need to create a FilterAction that will handle this. Is this the best place to do the IOC or is there a better place?
I have seen a lot of IOC examples that do the specification at design time and I but I could not find anything that made the IOC container via a filterAction or some other sort of post-login event.
Any help would be appreciated.
Ideally you should write a custom IDependencyResolver your your favorite DI framework. This resolver will be used by ASP.NET MVC to inject dependencies into common structures such as controllers. And to avoid reinventing the wheels search for a DI framework which already has an MVC extension to id adding this dependency resolver (probably the NuGet package will be suffixed with .MVC, for example Unity.Mvc3 or Ninject.Mvc3, ...). The container setup is then performed in your Application_Start.
Related
As we all know In asp.net Startup class there is a method ConfigureServices we can add custom Services. Services are made available through Dependency Injection.
ASP.NET Core includes a simple built-in inversion of control (IoC)
container that supports constructor injection by default, but can be
easily replaced with your IoC container of choice. In addition to its
loose coupling benefit, DI makes services available throughout your
app
My Question is how to Replace Built in IoC with my Own IoC?
Please provide me an example if you have.
There are a number of different containers currently available for ASP.NET Core, including
Autofac: http://docs.autofac.org/en/latest/integration/aspnetcore.html
StructureMap: http://andrewlock.net/getting-started-with-structuremap-in-asp-net-core/
SimpleInjector: https://simpleinjector.readthedocs.io/en/latest/aspnetintegration.html
DryIoc (RC2 only atm): https://bitbucket.org/dadhi/dryioc
Exactly how you use them differs in each case, but essentially they all follow the same pattern:
Register dependencies as usual using the built-in container
Create an instance of your third-party Container
Add any additional registrations to your third-party container
Populate the new container with registrations from the built-in container
Return an IServiceProvider from your third-party container
It might be worth taking note that there are a number of conversations happening around the way these libraries will integrate with the built in container going forward. The comment here provides a good summary of the conversation, or you can dive right into the discussions on GitHub here and here.
In our web project we are using Ninject. Now we are adding plugins to our application. We want plugins to be able to add their own bindings. Ninject modules seems like a logical solution to this problem.
However, I don't see any guidance on how to avoid the following problem. What if a plugin adds a binding to an interface that already had a binding. Now the DependencyResolver will throw an exception when trying to resolve that interface.
I'm trying to make a change to our DependencyResolver that doesn't require rewriting all of the binding statements we've already written in the main application. I don't want a plugin to be able to break my main application. If a plugin needs to apply constraints to make it's bindings work then it is its responsibility.
So here's what I want.
A plugin would not be able to break the core app or another plugin because it added a binding.
It should not be necessary for any change to be made to core application or another plugin when I want to add a new plugin with its own bindings
Where there are multiple instances to choose from it should do the "logical" thing. The core app should get the instance it always would have gotten in the absence of the new plugins. The plugin should get the instance it specifically bound.
It seems like I should be able to override the resolving methods of StandardKernel so that it can implement these rules. It seems like knowing what module a binding was a part of would help resolving. But I can't find module or module name as part of the context, request, bindinginfo, etc.
Any thoughts on how to resolve this issue. I don't see that Ninject seems to answer what seems like a very obvious need for a modular system. A new module shouldn't be able to break an app. (It should only be able to "break" itself.)
You should have a look at Ninject.Extensions.ChildKernel. You could create a ChildKernel per plug-in and then load the plugins' module in their own ChildKernel.
This means that a plugin cannot rely on the bindings of another plugin, but a plugin may rely on the bindings of the Parent Kernel (root / application kernel). So you can provide certain types/services to the plugins.
By the way, if the implementation of Ninject.Extensions.ChildKernel does not match your needs, you might very well choose to implement your own extension. It's not that much code (see ChildKernel source)
I am working on a silverlight project and I am using MEF to download xap file of other silverlight project and use its pages and functions in my main Project.
I can do the same thing using referencing dll of that project into my main project.
So I want to know what is the difference between using MEF to reusing components and Simply Adding Reference to the DLL of another project in current project? I mean that we also add reference to the project we import in our current project. Then how it is different from conventional form of component use?
Thanks,
First, we need to separate MEF and PRISM (since you used it in your tags).
MEF is primarily used to provide inversion of control (IoC). It makes it easy to manage dependencies your viewmodels and other classes to separate concerns and improve testability (amongst other benefits).
PRISM however is primarily designed for the following scenario: You don't know, what view goes into a specific container at compile time, and want ViewA for CustomerA, ViewB for CustomerB and so on. PRISM helps you to losely couple your regions and views in a way, so that the application can decide at runtime, what view will be displayed. Another scenario, is that administrators get one view, other users another etc. PRISM also has other features (like the event aggregator), but I'd say the former is the most important one.
Now, I'd say MEF is never a bad thing to use for a bigger project. But I'd only use PRISM, if you really need the functionality it provides, since it can be very limiting. If you don't, simply add the references as you explained and let MEF know about those assemblies with the AssemblyCatalog.
So for MEF, I'd suggest you learn about Depdendency Injection and IoC. I found this blogpost by Martin Fowler quite good. As for PRISM, get familiar with what it does, and decide if you really need it.
Hope this helps.
Let me complement Lue's answer on the difference between MEF and referencing dlls a bit:
The two things are orthogonal activities, meaning that if you reference a dll directly you might still want to use MEF to detect the types in it - and vice versa you might grab a specific type in a dll you dynamically loaded directly (without MEF).
MEF basically finds types in dlls according to certain criteria and has a bit of convenience stuff in it to automatically populate properties and collections with such types. It can be used to make a system more decoupled and thus more maintainable. For example, a video editing software may look for all types implementing a certain interface in all known dlls to use as filters. Whether you include the filters directly as a dll or let the user download them on demand: In both cases your application becomes slightly cleaner by using MEF, since there is no hard-coded list of filters anywhere. Still, in the presence of dynamic library loading MEF is especially useful.
I am trying to implement a global exception handler in Asp.NET MVC 4 beta. As I understand it I am supposed to implement an IExceptionFilter and add that to the filters collection. However I was unable to make it work when using the System.Web.Mvc.IExceptionFilter. Am I supposed to use that one, or is the System.Web.Http.Filters.IExceptionFilter (and related classes) the ones I should be using?
Asking another way:
Should I be adding filters to the GlobalConfiguration.Configuration.Filters or GlobalFilters.Filters?
System.Web.Http namespace completely belongs to ASP.NET Web API framework, not ASP.NET MVC.
As for the registration point, you need to add them into GlobalFilters.Filters collection.
So after getting some pointers from #tugberk, I realize my mistake. I was basically asking for the wrong thing. What I wanted was to be able to add filters for an ASP.NET Web API service, not add them for an mvc application.
I made this error thinking they were one and the same. I guess I must have read som of what was said about moving these things together the wrong way.
In any case. I should be using the System.Web.Http namespace for my case, which means adding to the GlobalConfiguration.Configuration.Filters collection.
I found a rather nice weblog showing a basic implementation of some of what I want to accomplish. Maybe it can help somebody else.
I have planned to write my own light weight MVC for PHP, that will be used as base for my sites I develop. I have no problem with PHP, OOP, et al. I have trouble on how to actually load Models In controllers and use them amd loading Controller values into Views. In short, I don't know how M-V-C interact behind the scenes.
Any tutorial (concentrating on that) or any contribution is welcomed!
Thanks!
ASP.NET MVC is open source: http://aspnet.codeplex.com/releases/view/58781
Edit: consider this: I believe you are trying to reinvent the wheel, thinking that those MVC framework out there are heavy and packed with uncessary features (acording to your double use of the word lightweigth). In my experience, I always ended up coding those extra "features" because a framework is required to evolve. Loading models In controllers, using them and loading controller values into views is just the begining. If you want to get started eventually, it would be a better investment to write some helper classes and methods: a popular pattern in the MVC world. Unless you are writing a MVC framework from scratch for fun and I am totally wrong (you said you needed a base to use for your sites ).
Best of luck!
Codeigniter is an open source MVC framework of php.
http://codeigniter.com/user_guide/overview/appflow.html
The major in MVC is first of all your controller class initiated and then calls view.
After google and check how other MVC works I decided to take this route. I redirect all my requests with .htaccess to index.php. Then there I define base paths. After all the definitions I include the core.php which in turn includes all core files to my mvc framework. Then in the same file I create Instances of Registry and router and the game starts from here!
Internals are a bit complex now but that is what I ended with!