I'm still groping around a bit with Castle Windsor. At the moment all my pages which need an IWindsorContainer instantiate one themselves through a property:
private IWindsorContainer WindsorContainer
{
get
{
if (_windsorContainer == null)
{
_windsorContainer = new WindsorContainer(new XmlInterpreter(Server.MapPath("~/CastleWindsorConfiguration.xml")));
}
return _windsorContainer;
}
}
I'm getting a little tired of copying and pasting this property and the backing field from page to page! Also I don't really understand the life cycle of the IWindsorContainer.
I'd much rather get one of these through a static property of some class, but does anyone know if I can consider it threadsafe? How do you guys work with IWindsorContainer?
The standard and recommended practice is to have one instance of the container per application.
See these related questions for further information:
Usage of IoC Containers; specifically Windsor
How to get instance of service in Windsor Castle
And yes, Windsor is thread-safe.
Related
So I recently found out about dependency injection and read a lot about the pros and cons and I was curious if it would be "good" using it in my app as i couldn't find an example of something like I have at the moment.
My app at the moment is 100% based on Ajax requests my typical controller looks like this:
public JsonResult Controller()
{
getStuff from the model
return JSON(info from controller)
}
Is DI a good choice for this situation? Or is are the benefits (if any) slim to none?
PS: I don't know if this matter much, but I only use 1 database.
If you have a large application with multiple dependencies then DI is a good choice. Even if your app is relatively small and only requires the database connection to be injected, this could be a good starting point for you into DI.
For the code example you provided, assuming you're using controller injection and you require a database connection, you'll end up with something similar to:
public class MyController
{
IDatabase database;
public MyController(IDatabase database)
{
this.database = database;
}
public JSONResult MyControllerMethod()
{
var myData = database.GetData();
return JSON(myData)
}
}
Then you would need to configure your DI container so it knows which concrete classes to inject for which interfaces - depending on the framework you use, this will differ slightly.
Given you don't have a lot of experience with it, keep in mind there will be a bit of a learning curve while you get your head around it. I'm assuming you're using WebAPI for your AJAX calls in which case this page is an excellent resource to get you started - http://www.asp.net/web-api/overview/advanced/dependency-injection
I've built some code that can rebuild expression trees so I can avoid triggering the no supported translation to SQL exception and it works fine as long as I call my function to replace the iqueryable. The problem is that I'd like it to automatically be applied to all queries in my project without having to worry about calling this function on each one separately. Is there any way that I can intercept everything?
I've tried using Reflection.Emit to create a wrapping provider and using reflection to replace it on the data context and it turns out that even with Reflection.Emit I can't implement the internal IProvider interface.
I've also tried replacing the provider with a RealProxy based class and that works for non-compiled queries, but the CompiledQuery.Execute method is throwing an exception because it won't cast to the SqlProvider class. I tried replacing the response to the Compile method on the provider with another proxy so I could intercept the Execute call, but that failed a check on the return type being correct.
I'm open to any other ideas or ways of using what I've already tried?
It's hard to tell whether this is an applicable solution without seeing your code, but if you have a DI-friendly app architecture you can implement an interceptor and have your favorite IoC container emit the appropriate type for you, at run-time.
Esoteric? A little. Consider an interface like this:
public interface ISomeService
{
IEnumerable<SomeEntity> GetSomeEntities();
// ...
}
This interface might be implemented like this:
public class SomeService : ISomeService
{
private readonly DbContext _context // this is a dependency!
private readonly IQueryTweaker _tweaker; // this is a dependency!
public SomeService(DbContext context, IQueryTweaker tweaker) // this is constructor injection!
{
_context = context;
_tweaker = tweaker;
}
public IEnumerable<SomeEntity> GetSomeEntities()
{
return _tweaker.TweakTheQuery(_context.SomeEntities).ToList();
}
}
Every time you implement a method of the ISomeService interface, there's always a call to _tweaker.TweakTheQuery() that wraps the IQueryable, and that not only gets boring, it also feels like something is missing a feature - the same feeling you'd get by wrapping every one of these calls inside a try/catch block, or if you're familiar with MVVM in WPF, by raising this annoying PropertyChanged event for every single property setter in your ViewModel.
With DI Interception, you factor this requirement out of your "normal" code and into an "interceptor": you basically tell the IoC container that instead of binding ISomeService directly to the SomeService implementation, you're going to be decorating it with an interceptor, and emit another type, perhaps SomeInterceptedService (the name is irrelevant, the actual type only exists at run-time) which "injects" the desired behavior into the desired methods. Simple? Not exactly.
If you haven't designed your code with DI in mind (are your dependencies "injected" into your classes' constructor?), it could mean a major refactoring.
The first step breaks your code: remove the IQueryTweaker dependency and all the TweakTheQuery calls from all ISomeService implementations, to make them look like this - notice the virtualness of the method to be intercepted:
public class SomeService : ISomeService
{
private readonly DbContext _context
public SomeService(DbContext context)
{
_context = context;
}
public virtual IEnumerable<SomeEntity> GetSomeEntities()
{
return _context.SomeEntities.ToList();
}
}
The next step is to configure the IoC container so that it knows to inject the SomeService implementation whenever a type's constructor requires an ISomeService:
_kernel.Bind<ISomeService>().To<SomeService>();
At that point you're ready to configure the interception - if using Ninject this could help.
But before jumping into that rabbit's hole you should read this article which shows how decorator and interceptor are related.
The key point is, you're not intercepting anything that's internal to LINQ to SQL or the .NET framework itself - you're intercepting your own method calls, wrapping them with your own code, and with a little bit of help from any decent IoC container, you'll be intercepting the calls to methods that call upon Linq to SQL, rather than the direct calls to Linq to SQL itself. Essentially the IQueryTweaker dependency becomes a dependency of your interceptor class, and you'll only code its usage once.
An interesting thing about DI interception, is that interceptors can be combined, so you can have a ExecutionTimerServiceInterceptor on top of a AuditServiceInterceptor, on top of a CircuitBreakerServiceInterceptor... and the best part is that you can configure your IoC container so that you can completely forget it exists and, as you add more service classes to the application, all you need to do is follow a naming convention you've defined and voilà, you've just written a service that not only accomplishes all the strictly data-related tasks you've just coded, but also a service that will disable itself for 3 minutes if the database server is down, and will remain disabled until it's back up; that service also logs all inserts, updates and deletes, and stores its execution time in a database for performance analysis. The term automagical seems appropriate.
This technique - interception - can be used to address cross-cutting concerns; another way to address those is through AOP, although some articles (and Mark Seeman's excellent Dependency Injection in .NET) clearly demonstrate how AOP frameworks are a less ideal solution over DI interception.
I am using Ninject together with MVC3 to inject my controller dependencies. Sometimes I get slow timings in MVC Mini profiler even before the controller actions are executed. Since I don't do much before that time I thought it might be an issue with my usage of Ninject. Is there an existing way to get some timing information from ninject? Perhaps a config option to log how long dependency resolution took or if not what would be a good way to add this myself, is there a class I can extend or wrap?
You can write a decorator for the NinjectDependencyResolver by implementing the IDependencyResolver interface and replace it on the DependencyResolver.
DependencyResolver.SetResolver(new ProfilingResolver(DependencyResolver.Current));
public class ProfilingResolver : IDependencyResolver
{
private readonly IDependencyResolver decoratedResolver;
public ProfilingResolver(IDependencyResolver decoratedResolver)
{
this.decoratedResolver = decoratedResolver;
}
public object GetService(Type serviceType)
{
using (MiniProfiler.Current.Step("Get_" + serviceType.Name))
{
return this.decoratedResolver.GetService(serviceType);
}
}
public IEnumerable<object> GetServices(Type serviceType)
{
using (MiniProfiler.Current.Step("GetAll_" + serviceType.Name))
{
return this.decoratedResolver.GetServices(serviceType);
}
}
}
Firstly, my default answer would be:-
I've never seen DI showing up as a statistically significant percentage of anything interesting in a profile. Go Compose!
(This post started life as a comment:- #olle have you looked at the source? There are a number relatively simple extensions that 'wrap' the resolution process and shouldnt be too complex to grok. Given that you're using the Mini Profiler and it's pretty easy to stuff things into, it'd seem to be a relatively straightforward extension to do. I know this is a PITA response to get on a forum but I personally am thankful for being told to go Use The Source a few years back - the Ninject code base and its tests are a genuine joy to read.)
I find myself struggling with the fuzz around the concept of string-based 'Service Locators'.
For starters, IoC is great, and programming to interfaces is the way to go. But I fail to see where the big benefit lies in the yellow-pages pattern used here, apart from compilation-less reconfigurability .
Application code will use a (Spring) container to retrieve objects from. Now that's nice: since the code needs to know only the needed interface (to cast to), the Spring container interface, and the name of the needed object, a lot of coupling is removed.
public void foo(){
((MyInterface) locator.get("the/object/I/need")).callMe();
}
Where, of course, the locator can be populated with a gazillion of objects of all kind of Object derivatives.
But I'm a bit puzzled by the fact that the 'flexibility' of retrieving an object by name actually hides the dependency in a type-unsafe, lookup-unsafe manner: where my compiler used to check the presence of a requested object member, and it's type, now all of that is postponed to the runtime phase.
The simplest, functionally allright, pattern I could think of is a giant, application wide struct like object:
public class YellowPages {
public MyInterface the_object_i_need;
public YourInterface the_object_you_need;
....
}
// context population (no xml... is that bad?)
YellowPages locator = new YellowPages();
locator.the_object_i_need=new MyImpl("xyx",true),
locator.the_object_you_need=new YourImpl(1,2,3)
public void foo(){
locator.the_object_i_need.callMe(); // type-safe, lookup-safe
}
Would there be a way/pattern/framework to ask the compiler to resolve the requested object, and check whether it's type is ok? Are there DI frameworks that also do that?
Many thanks
What you are describing is an anti-pattern, plain and simple. Dependency injection (done via the constructor if possible) is the preferred way to do Inversion of Control. Older articles on IOC talk about service location as a viable way to implement the pattern, but you'd be hard pressed to find anyone advocating this in more recent writings.
You hit the nail on the head with this statement:
But I'm a bit puzzled by the fact that the 'flexibility' of retrieving
an object by name actually hides the dependency in a type-unsafe,
lookup-unsafe manner:
Most modern DI frameworks can get around the type-unsafe part, but they do hide the dependency by making it implicit instead of explicit.
Good article on this topic:
Service Locator is an Anti-Pattern
Spring is the only DI framework that I've used, so I can't speak for others, but even though Spring give you the ability to request an object by its name in your code, you don't have to get your Spring beans by name -- in fact, if you do, you're not really capitalizing on the "I" (inversion) in IOC.
The whole principle behind Spring/DI is that your objects shouldn't be asking for a particular object -- it should just have whatever objects it needs handed to it by the IOC container. The distinction is subtle, but it's there. The former approach would resemble the code that you pasted:
public void foo(){
((MyInterface) locator.get("the/object/I/need")).callMe();
}
The latter approach, by contrast, doesn't depend on any service locator, nor does it depend on the "name" of the object that it wants:
private ObjectINeed objectINeed;
public void setObjectINeed(ObjectINeed objectINeed) {
this.objectINeed = objectINeed;
}
public void foo(){
objectINeed.callMe();
}
It's the IOC container that calls the setObjectINeed() method. DI is definitely tackles the same problem as the service locator pattern, but it goes that extra step towards getting rid of the dependency on your service locator class.
The short question:
Does Castle Windsor have something similar to Spring.Net's "Lookup Method Injection" that can be configured from XML, which provides the ability to fetch transient instances from the container without the class being aware of the IoC container?
The long question:
I'm a long time Spring/Spring.Net user and I have been experimenting with Castle Windsor, by trying to port a project over to it. Spring.Net has a concept of "Lookup Method Injection" which (from the Spring docs)...
Lookup method injection is the ability of the container to override methods on container managed objects, to return the result of looking up another named object in the container. The lookup typically involves a prototype object as in the scenario described in the preceding section. The Spring framework implements this method injection by a dynamically generating a subclass overriding the method using the classes in the System.Reflection.Emit namespace.
What this means is, If I had the following...
public class SomeTransient
{
// ... I have dependencies that need to be filled by IoC container
}
public class SomeClass
{
public virtual void Work()
{
var o = CreateTransient();
}
public virtual SomeTransient CreateTransient() { }
}
I can instruct Spring to override the CreateTransient method, and have that method return a new container created transient instance (with it's dependencies initialized) each time the method is called.
The unique part of this is, it doesn't require direct links to the Spring Framework (eg. SomeClass doesn't have to implement a specific interface).
Is there something similar in Castle Windsor to accomplish this via XML?
(I will eventually move away from XML config, but at the moment I'm just trying to get it running)
Castle has something better; Typed Factories.
You can also inject even a delegate!
http://stw.castleproject.org/Windsor.Typed-Factory-Facility-delegate-based-factories.ashx
It is better because it does not depend on dynamically generation code, and it looks much more cleaner.
It looks much more cleaner because the class doesn't depend on someone overriding that method. It is impossible to test this class without subclassing.
If you really want to do something like this, i would expect:
public abstract class SomeClass
{
public abstract SomeTransient CreateTransient();
}
but... again it doesn't feel right.
Edit 2
Unity 2 support these kind of delegate factories; you can read more here:
http://www.truewill.net/myblog/index.php/2010/05/06/unity_2_0_combining_injectionfactory_and
thanks to #eiximenis