Every now and then people get confused when they try to use the NinjectObjectBuilder for NServiceBus. In this blog post I want to describe the purpose of the NinjectObjectBuilder for NServiceBus and highlight the difference between Ninject and Ninject together with NServiceBus.
We all know that people have been struggling to adapt the modularity and composition root approach Ninject and particularly the people around Ninject have been promoting over the years. After several years of stackoverflow frustration and people constantly demanding new feature for Ninject, we sat down and decided to listen carefully to the people’s needs. After endless meetings with no real agenda we finally came to the ultimate conclusion:
Ninject’s way addressing modern application composition is completely flawed. People don’t want modularity or composition roots. They always have been using Service Locator style dependency resolving and don’t want to learn new techniques. So here is the big announcement:
We will no longer support modularity and composition root; thereby completely deprecating all existing APIs and extensions for Ninject in the next major version.
The new interface we came up after a long design session will look like the following:
Ninject.Kernel.Instance.Locator.Resolve<TService>(params object constructorArguments);
Under the hood it will use ultra rocket science expression tree dynamic lambda compile algorithm. The algorithm is kept under copyright and will not be part of the usual Apache and MS Public licensed public code but instead be hosted on a private github repository. But what I can say here is that the output of the dynamically generated code will look like the following:
return Activator.CreateInstance(typeof(TService), constructorArguments);
We strongly advice against trying this code at home! It can lead to serious out of memory damage!
But wait there is more! We even sat down with Anders Hejlsberg and the next major C# upgrade will use Ninject under the cover. It will be possible to do DI with the new keyword. Your dreams will come true! You’ll then be able to write code like this:
new IFoo(new IBar(42));
This will then automagically (using the new compiler services) be transformed into:
This feature is so powerfull that there will never again be a new Ninject release. All will be baked in the new keyword. Happy service locating!
Yes I know I promised you guys amazing things are happening in NServiceBus. But I want to start with the small things and then go over some bigger changes. So feel free to skip this blog post if I disappointed you 😉 NServiceBus 3.0 and greater has the notion of an unit of work. The unit of work in NServiceBus allows you to externalize repetitive code such as committing NHibernate transactions, calling SaveChanges on a RavenDB session and much more. You can create your own unit of work pretty easily by just implementing the IManagesUnitOfWork interface and registering it in the provided container abstraction of NServiceBus. Let us explore an example…
Since I started using and working on Ninject I have never seen a good use case for Activations Blocks like they are implemented at the moment. That’s why I’m currently planning on changing their behavior to give them more sense. This blog post will explain what I have in mind at the moment.
Unfortunately, ASP.NET providers like the MembershipProvider and RolesProvider aren’t designed for dependency injection. Many users have problems to assign dependencies to them. In this blog post I’ll show a way to how this can be done using Ninject.Web.Common 3.0.0. This solution works for MVC and WebForms. Continue reading
The new release of Ninject 3.0 comes with a new extension that adds support for factories to Ninject. It supports factory interfaces, Func and Lazy. In this blog post I will explain how they are used.
Why using factories?
The recommended way to use IoC containers is that the composition root of the application is the only place where the container is accessed. Unfortunately many application can’t create everything at once during the application start or at the beginning of a web/wcf request because not everything is known at this moment. Therefore these applications need a way to create new instances using the kernel at a later point. Preferably we want to do this without introducing a reference to the container. This is where factories come into play. Instead of injecting the kernel into classes that need to create new instances we inject a factory. This factory is responsible to create the new instances using the kernel. There are two ways to implement such a factory: A factory interface and as a Func or Lazy.
Ninject 3.0 release candidate has gone live. This release introduces some new feature and some changes in its behavior. This blog post will give you detailed information what has changed. It covers mainly Ninject core. Other blog posts that describe the changes and the new extensions will follow soon.
Lately, I wrote quite a lot of acceptance tests. I simulate that the application is started-up and perform all features requested by our customer to make sure that they work as expected. In order to make these tests fast so that they can be run on every commit to the version control system, I simulate all interaction with the environment of the application: views, database, file system, registry, share point and so on.
To get the most out of these acceptance tests, I want to fake as little as possible. And here comes the Rebind feature of Ninject into play. I can bootstrap the application as in production and then replace all components interacting with the environment by simple calls to Rebind.
Ninject 2.4 will introduce the ability to configure which constructor shall be used and to configure constructor arguments without having to use magic strings to define for which argument. In this post I will give a preview on how this works.
Recently we have updated all Ninject Nuget packages to Nuget 1.3. In order to use them you have to update your client to 1.3 as well. This update brought a few improvements: