I've used MEF for a few projects at work and I've just stared messing about with Monorail in my spare time. I was wondering if there was any way that I could use MEF to load the controllers that Monorail uses. Monorail appears to look for controllers in assemblies that you list in the Web.Config:
<controllers>
<assembly>my.assembly</assembly>
</controllers>
Is there a way that 'my.assembly' can then use MEF to load up more controllers? I have to admit I haven't though of a reason I would need this functionality but I'm just trying things out!
Monorail is a very extensible framework. Almost everything is being provided by a service that can be easily switched with something else.
For e.g., IoC integration is quite easy, as you can switch the services that creates controllers, filters, helpers, and all other MonoRail entities.
Concrete example: Integrating Windsor container into Monorail
Now this sets up almost everything in the Monorail to be provided by Windsor. If you only want Controllers to be provided by MEF, there's even less work.
I have very little working knowledge of MEF so it might be a little off, but you'd get the general idea:
Use MEF discovery mechanisms to locate controller types, then add controller types to the default IControllerTree service. take a peek at MonoRailFacility.cs for inspiration.
Implement a MefControllerFactory : IControllerFactory that will use MEF to instantiate controllers when needed. Inspiration is at WindsorControllerFactory.cs
It's not something you can use yet, but have a look at Hammett's blog post here, where he talks about what he is prototyping for MonoRail 3.0 (including support for MEF by default).
Related
I'm moving from StructureMap 2.x to 3.x. One major change is that using ObjectFactory results in the following warning:
'StructureMap.ObjectFactory' is obsolete: 'ObjectFactory
will be removed in a future 4.0 release of StructureMap. Favor the
usage of the Container class for future
work'
So in most cases, the resolution is fairly easy: pass through IContainer as a constructor. Unfortunately this is not feasible for ASMX web serivces or attributes, both of which require a default constructor. That means I'm probably stuck with the Service Locator Pattern, property injection, or writing my own ObjectFactory implementation.
What's the preferred way to deal with this unfortunate problem?
Edit: It's worth mentioning that my container does an Assembly scan.
Per Jeremy Miller, himself:
Assembly scanning isn’t cheap and you (almost?) always wanna cache the
results. So, yeah, in that case you’re going to have to write your
own ObjectFactory. Someday all that bad old MS tech will go away.
So in this case, this implementation is what should be done.
The cleanest way I have seen to deal with this is to use .NET routing to take control of the entry point, then make a custom PageHandlerFactory implementation that takes the DI container as a dependency.
The custom page handler factory will then property inject the page/service after it is instantiated but before any of its events are called.
This is almost exactly the same way that IControllerFactory works with DI in MVC. In MVC, the container is injected into a custom IControllerFactory implementation at application startup, which effectively makes it a part of the application's composition root. In the case of ASP.NET, the IRouteHandler would effectively be part of the composition root.
I was unable to find a link to the source where I originally saw that implementation. But this one is pretty close. The primary difference is that one tries to use constructor injection, but the downside is that it requires full trust to do. I believe if you stick with property injection, you can do it with partial trust.
I need to fetch data from an external API, only accessible via VPN.
The development/test machine will not always be able to connect to the VPN.
The desired behaviour is to use two different implementations (one that calls the actual external API and one that acts as the real thing but returns dummy data). Which implementation to use will be configured via a flag in web.config
I've tried the IoC containers StructureMap and Unity and they both did the job but they only seem to be applicable for MVC, I'm looking for a generic solution that also works for web forms. And also, isn't it a bit overkill to use them for this isolated design problem!?
Is there a design pattern or best practice approach for this particular scenario?
IoC / dependency injection sounds like the correct approach, but you don't necessarily need a container for a simple scenario. The key is to have classes that depend on the API reference an interface IAPI, and pass it the actual implementation RealAPI or FakeAPI.
public class SomeClass
{
private readonly IAPI _api;
public SomeClass(IAPI api)
{
_api = api;
}
}
Now you should be able to switch out the implementation easily by passing a different object to MyClass. In theory, when you're using an IoC approach, you should only need to bind the interface to the implementation once, at the top level of the application.
isn't it a bit overkill to use them for this isolated design problem!?
They probably are. Those IoC containers only help you when you wrote loosly coupled code. If you didn't design your classes according to the SOLID principles for instance, those frameworks will probably only be in the way. On the other hand, which developer doesn't want to write loosly coupled code? In other words, IoC container solves a problem you might not have but it's a nice problem to have.
StructureMap and Unity [...] only seem to be applicable for MVC
Those ioc frameworks can be used in any type of application (as long as it is written in loosly coupled way). Some types of applications need a bit more work to plug a framework in, but it's always possible. StructureMap and Unity might only have integration packages for MVC, it's quite easy to use them in ASP.NET Web Forms as well.
Is there a design pattern or best practice approach for this
particular scenario?
What you're looking for is the Proxy pattern and perhaps the circuit breaker pattern.
I am designing some architectural changes into a legacy ASP.NET application. I prototyped some classes for dependency resolution that mimic the ASP.NET MVC's IDependencyResolver. I won't post because it is pretty much the same interface, but in other natural language.
I figured out it might be considered Service Location, which in turn is usually (not fully in some cases) condemned in favor of Dependency Injection. Nevertheless, I couldn't find any recommendation against the use of the ASP.NET MVC's dependency resolution implementation.
Is the ASP.NET MVC's IDependencyResolver considered an anti-pattern? Is it a bad thing?
If you look at the signature you will see that it's just a Service Locator with another name. Service Locator is an anti-pattern and I consider the relationship transitive, so I consider IDependencyResolver an anti-pattern.
Apart from that, the interface is also broken because it has no Release method.
I don't believe so... You can inject any IoC you want into ASP.NET MVC, which seems like a pretty good pattern to me.
Here's a blog post about injecting Unity into ASP.NET MVC 3.
I know what Dependency Injection is in theory, but I haven't ever actually used Dependency Injection in any of my projects yet. So consider me to be a DI noob.
The straightforward question is; Can MEF be used for Dependency Injection?
If it can, my follow up question is; Is it a good idea to use MEF for dependency Injection?
I understand that my follow up question may be viewed as being subjective. But, I am looking for best practices and reasons for and against. So, I hope that my follow up question doesn't rustle too many feathers.
The context of all this is I feel a little lost trying to figure out how to make a plugin framework for asp.net mvc.
As I explain in my book MEF can be used as a DI Container, but in its current incarnation it's not particularly well-suited for the task.
MEF was designed to address extensibility scenarios, and while it has a lot of overlapping features, it's quite limited when it comes to configuration and lifetime management.
MEF can, I believe, be used for dependency injection; at least I use it in my own small home WPF project currently. I suspect it might get messy when you need to inject different types for an interface for different deployments of your application, if you require this. It would require going to some effort to add the right classes to your catalog.
Where I work, using ASP.NET MVC2, we use Castle Windsor for dependency injection. We make use then of the XML configuration to initialize the container. This means we can inject different types for an interface without having to rebuild.
I believe .NET offers another option to MEF, similarly called MAF. It's supposed to be more complex, but offer much more control. I don't however know anything more about it.
(I'm not very experienced (1 year employed), so if someone disagrees with my on something, they're probably more correct)
Glenn Block (former product manager of MEF) answered this FAQ in a blog post.
Most of the shortcomings of MEF mentioned in his post have been addressed by MEFContrib: it contains additional catalog and export provider implementations to add support for POCOs, open generics and interception.
update: the recently released MEF2 Preview3 adds support for open generics and attribute-less registration out of the box. The APIs of preview releases aren't final but this is a good indication that those features will be in the next (>v4.0) .NET release .
I am currently writing an open source SDK for a program that I use and I'm using an IoC container internally(NInject) to wire up all my internal dependencies.
I have some objects that are marked as internal so that I don't crowd the public API as they are only used internally and shouldn't been seen by the user, stuff like factories and other objects. The problem that I'm having is that NInject can't create internal objects which means that I have to mark all my internal objects public which crowds up the public API.
My question is: Is there someway to get around this problem or am I doing it all wrong?
PS. I have thought about using InternalsVisiableTo attribute but I feel like that is a bit of a smell.
Quick look at the other answers: it doesn't seem like you are doing something so different that there is something fundamentally wrong with Ninject that you would need to modify it or replace it. In many cases, you can't "go straight for [the] internals" because they rely upon unresolved dependency injection; hence the usage of Ninject in the first place. Also it sounds like you already do have an internal set of interfaces which is why the question was posed.
Thoughts: one problem with using Ninject directly in your SDK or library is that then your users will have to use Ninject in their code. This probably isn't an issue for you because it is your IoC choice so you were going to use it anyway. What if they want to use another IoC container, then now they effectively have two running duplicating efforts. Worse yet what if they want to use Ninject v2 and you've used v1.5 then that really complicates the situation.
Best case: if you can refactor your classes such that they get everything they need through Dependency Injection then this is the cleanest because the library code doesn't need any IoC container. The app can wire up the dependencies and it just flows. This isn't always possible though, as sometimes the library classes need to create instances which have dependencies that you can't resolve through injection.
Suggestion: The CommonServiceLocator (and the Ninject adapter for it) were specifically designed for this situation (libraries with dependencies). You code against the CommonServiceLocator and then the application specifies which DI/IoC actually backs the interface.
It is a bit of a pain in that now you have to have Ninject and the CommonServiceLocator in your app, but the CommonServiceLocator is quite lightweight. Your SDK/library code only uses the CommonServiceLocator which is fairly clean.
I guess you don't even need that. IoC is for public stuff. Go straight for internals.
But - that's just my intuition...
Create a secondary, internal API which is different from the external API. You may need to do the split manually...
I'm going to vote for the InternalsVisibleTo solution. Totally not a smell, really. The point of the attribute is to enable the sort of behavior you are wanting, so rather than jumping through all sorts of elaborate hoops to make things work without it, just use the functionality provided by the framework for solving this particular problem.
I would also suggest, if you want to hide your choice of container from the user, using ILMerge to combine the Ninject assemblies with your SDK assembly, and apply the /internalize argument to change the visibility of the Ninject assemblies to internal, so the Ninject namespaces don't leak out of your library (sorry, couldn't find a link to the ILMerge docs online, but there is a doc file in the download). There is also this nice blog post about integrating ILMerge into your build process.
You can
modify Ninject
pick a different container