Has anybody tried to use StructureMap for IoC with Rhino.Commons?
Thanks
Windsor is deeply rooted in Rhino Commons, a search for "Windsor" in the source code gives back 45 files. Binsor, for example, is very specific to Windsor. However, it shouldn't be very difficult to refactor some parts of Rhino.Commons to use CommonServiceLocator instead of Windsor, effectively making it container-provider-independent.
It's unlikely that you want all of Rhino.Commons, so my question to you is: what part(s) of Rhino.Commons do you need?
Looking at the source code I don't see how it would be possible. The IoC.Initialize() method takes in an IWindsorContainer.
Related
I wish to replace the implementation of System.Web.Mvc.ActionMethodSelector as used by the FindAction method of ReflectedControllerDescriptor, but would like to take advantage of the existing implementation, ideally by deriving from ActionMethodSelector. However, because the class is marked as internal the only way I can see to do this 'properly' is to derive from ReflectedControllerDescriptor and implement FindAction by copying the code from ActionMethodSelector. I wish to avoid this however due to the quantity of code, and potential issues trying to keep it up to date with the framework.
I'm considering the following approaches:
Biting the bullet and copying the code
Using reflection so as to take advantage of the existing implementation
Are there any other approaches that I'm missing, better or otherwise?
I know it is a bit late to answer still I am giving it a try.... :)
I believe that you somehow want to tweak action method selection process in ASP.NET MVC. If my understanding is correct you can make use of custom ActionMethodSelectorAttribute by deriving from System.Web.Mvc.ActionMethodSelectorAttribute. Write your own custom logic in the custom selector and apply it on the top of the action methods. I believe in this way the action method selection process can be tweaked without disturbing the natural process.
If you wish you can visit these links: http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and.html, http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and_2.html
I have a bit of a dilemma, which to be honest is a fringe case but still poses an issue.
Currently I am using Ninject MVC and bind all my controllers like so:
Kernel.Bind<SomeController>.ToSelf();
Which works a treat for 99% of things that I have needed to do, however at the moment I am doing some wacky stuff around dynamic routing and dynamic controllers which require me to manually write a method to get the type of a controller from ninject. Now initially I thought it would be easy, but its not... I was expecting that I could get the controller based on its name, but that didnt work.
Kernel.Get<IController>("SomeController");
That got me thinking that its probably because it only knows about a binding to SomeController, not IController. So I thought, I can just write all my bindings like so:
Kernel.Bind<IController>.To<SomeController>().Named("SomeController");
This way it should be easy to get the type of the controller from the name doing the previous code, however if I were to bind this way, I would have a problem when I come to unbind the controllers (as plugins can be loaded and unloaded at runtime). So the normal:
Kernel.Unbind<SomeController>()
Which was great, will no longer work, and I would have to do:
Kernel.Unbind<IController>();
However then I realised that I need to give it some constraint to tell it which binding for this type I want to unbind, and there seems to be no overloads or DSL available to do this...
So I am trapped between a rock and a hard place, as I need to satisfy the ControllerLookup method, but also need to keep it so I can add and remove bindings easily at runtime.
protected override Type GetControllerType(RequestContext requestContext, string controllerName) {
//... find and return type from ninject
}
Anyone have any ideas?
(Just incase anyone questions why I am doing this, its because of the way I am loading plugins, Ninject knows about the types and the namespaces, but within the context of creating a controller it doesn't know the namespace just the controller name, so I do this to satisfy the isolation of the plugin, and the location of the dynamic controller, it is a roundabout way of doing it, but it is what people have done with AutoFac before Example of similar thing with AutoFac)
In my opinion the bindings should be created once at application startup and not change anymore after the first resolve. Everything else can lead to strange issues. Unless you have proper isolation using an AppDomain for each plugin you can not really unload them anyway. Instead of unloading bindings you can make them conditional and disable them using some configuration.
If you really want to unload bindings then I suggest not to do it for single bindings but take advantage of modules. Load all bindings belonging to one plugin together in one or several modules and unload those modules instead of the single bindings.
Im new to Autofac and finding myself repeating a lot of this....
builder.RegisterType<ConcreteService<EntityA>>().As<IService<EntityA>>();
builder.RegisterType<ConcreteService<EntityB>>().As<IService<EntityB>>();
EntityA, EntityB, EntityC and so on.. all inherit from EntityBase, so i want to instruct Autofac to always use ConcreteService<x> when it needs to create an implementation of IService<x> as long as x inherits from EntityBase
I am aware that the AssemblyScanner in Autofac may be able to help with this, although i am struggling to find documentation that goes far enough into it.
Any pointers appreciated.
I think the answer to this question (stackoverflow) may also answer your question.
Is there a way to get a list of all the Views defined in an ASP.NET MVC project? Is there a built-in enumeration anywhere or should I be looking toward reflection?
Programmatically accessible View Names is one of the many features offered by the T4MVC template. If it should not fit your needs exactly, you can still have a look and see how it's done there.
Reflection is your friend in this case. I don't think the enumeration exists already.
Kindness,
Dan
something along these lines should get you started
for (methods in controller)
typeof(ActionResult).IsAssignableFrom(methodInfo.ReturnType)
that's pseudo, not sure if it's the proper properties and what not... the one thing you'll have to be careful of is only get methods on the declaringtype, not on the base types.
typeof(Controller).GetMethods(
BindingFlags.Instance |
BindingFlags.DeclaredOnly |
BindingFlags.Public)
hope that's enough to be dangerous and get you started.
Since ASP.NET MVC favors convention over configuration, your best bet is to look at all the files under the ~/Views directory -- no reflection needed.
In order to write testable C# code, I use DI heavily.
However lately I've been messing around with IronPython and found that as you can mock any methods/classes/functions etc... you like, the need for DI is gone.
Is this the case for dynamic langagues such as Python?
Instead of:
class Person(Address) {
...
You can have:
class Person() {
...
// Address initialised in here.
For dynamic languages and therefore following manaual DI for dynamic langagues is simply not needed.
Any advice on this?
Dependency Injection is also about how you wire things together --- which has nothing to do about the mockability of depended-on objects. There's a difference between having a Foo-instance that needs a Bar-connection of some kind instantiate it directly and having it completely ignore how it gets that connection as long as it has it.
If you use dependency injection you also gain better testability. But the converse isn't true. Easier testability by being able to overwrite anything doesn't bring the other advantages of dependency injection. There are many component/DI-frameworks for Python available exactly for these reasons.
I strongly disagree with your statement that Dependency Injection is not needed in dynamically typed languages. The reasons for why DI is useful and necessary are completely independent of the typing discipline of the language.
The main difference is that DI in dynamically typed languages is easy and painless: you don't need a heavyweight framework and a gazillion lines of XML configuration.
In Ruby, for example, there are only two DI frameworks. Both were written by a Java programmer. Neither of the two frameworks is used by a single project. Not even by the author of those frameworks.
However, DI is used all over the place in Ruby.
Jamis Buck, who is the author of both of those frameworks gave a talk called Recovering from Enterprise at RubyConf 2008 about how and why he wrote those frameworks and why that was a bad idea, which is well worth watching. There’s also an accompanying blog post if you’d like to read. (Just substitute “Python” everytime he says “Ruby” and everything will be just as valid.)
I'll try again. My last answer missed the question by a mile and zoomed way off topic.
Using pseudo-code, dependency Injection says out with:
class Person
def Chat() {
someOperation("X","Y","Z")
end
end
...
Person.new().Chat()
and in with:
class Person
initialize(a,b,c)
#a=a
#b=b
#c=c
end
def Chat()
someOperation(#a,#b,#c)
end
end
...
Person.new("X","Y","Z").Chat()
,., and generally in with putting the object and the call into different files for SCM purposes.
Whether "X", "Y" or "Z" are mockable (...if they were instead objects...(!)...(!)...) have nothing at all to do with whether DI is good. Really. :-)
DI is just easier in Python or Ruby, like a lot of other tasks, because there's more of a scripting approach, like Jörg says; and also of course less of a culture and a tendency saying that constants and adapters are to get populated into models and global constants.
In practical terms for me DI is the first step towards separating out those application parameters, API constants and factories into separate files to help make your revision tracking report look less spaghetti-like ("Were those extra checkins on the AppController to change the configuration..? Or to update the code...?") and more informing, and more easy to read.
My recommendation: Keep using DI... :-)
I think you're presenting a question that seems to be about best practice but is actually about run-time performance.
Get rid of dependency injection? How can a software release manager sleep at night?
The tests for function to perform must surely slow the program down one or two tads.
// my generic function entry point - IronPython
if func="a":
...
if func="b":
...
if func="c":
...
You can use standard Python with classes... or you can assign function pointers to function pointer members. Just what kind of a beast is it...?? I know, I know. Python I think is difficult to define but I like it. And I like and think highly of dependency injection, not that I've had long where I'd think to assign such a lengthy name to the practice.