Develop Reference

Adjust Unity Dependency injection to use Lazy<T> / Func<T>

I'm working on a project that uses Unity Dependancy injection but the load performance is slowly getting worse. I am trying to adjust the code to utilise Lazy<T> (or Func<T>) so i'm trying to find a way to either register the classes with the container using Lazy<T> (or Func<T>) or have some sort of factory that could either adjust the registered types or the constructor but i am not able to seem to find a possible way to do this
At present i have numerous service classes like
public Service1(IClassLogic<GetReq, GetRes> getClass, IClassLogic<AddReq, AddRes> addClass, IClassLogic<UpdateReq, UpdateRes> updateClass, IClassLogic<DeleteReq, DeleteRes> deleteClass....){...}
then i have registrations similar to
container.RegisterType<IClassLogic<GetReq, GetRes>, GetClass>();
container.RegisterType<IClassLogic<AddReq, AddRes>, AddClass>();
container.RegisterType<IClassLogic<UpdateReq, UpdateRes>, UpdateClass>();
container.RegisterType<IClassLogic<DeleteReq, DeleteRes>, DeleteClass>();
...
Ideally i would like not to have to go an change all the signatures to
public Service1(Lazy<IClassLogic<GetReq, GetRes>> getClass, Lazy<IClassLogic<AddReq, AddRes>> addClass...
Any pointers would be greatly appreciated

Prevent using Func<T> and Lazy<T> as dependencies to prevent slow object graph initialization. These are leaky abstractions, because they leak implementation details into the consumer. The implementation detail here is that such service is costly to create.
The fact that it takes too much time to create a dependency is an indication that your injection constructors do too much, while they should be simple, fast and reliable.
Another obvious problem is the Single Responsibility Principle violation in your components. Having more than 5 dependencies in a constructor is a code smell and an indication of a Single Responsibility Principle violation. Some containers get slower when you need to resolve really big object graphs, but when you make your components small and focussed, this problem will quite likely go away, since the object graph to construct will be much smaller.

First off some tips concerning DI in general:
You're right, you do not want to change the signature of the constructor. You're IoC container (Unity in your case) should enable you to design the interfaces and consumers as you like. Otherwise it isn't a good container.
When struggling starting with DI (and containers) I would advise wiring it up yourself. This gives you great insight in how it works and provides flexibility. Mark Seemann has written a lot about this stuff.
Your service's dependencies seem awfully crowded. Can't you refactor to less dependencies by combining some (maybe by a Facade)?
Making interfaces specific (not generic) makes things a lot simpler. Generics sometimes cause more harm than good.
I've coded up a quick example which compiles (I haven't tested it). I've used a generic interface in line with your example but used some fake implementation and string types as generic params (which aren't used):
If this is an implementation of an interface:
public class ClassLogic : IClassLogic<string, string>
{
public void Do()
{
// do stuff
}
}
Then you could implement a provider which only creates the implementation when needed (via a given Func) like this:
public class ClassLogicProvider : IClassLogic<string, string>
{
private readonly Func<IClassLogic<string, string>> innerLogicFactory;
public ClassLogicProvider(Func<IClassLogic<string, string>> innerLogicFactory)
{
this.innerLogicFactory = innerLogicFactory;
}
public void Do()
{
var classLogic = this.innerLogicFactory();
classLogic.Do();
}
}
And wire it up like this:
var container = new UnityContainer();
Func<IClassLogic<string, string>> classLogicFunc = () =>
{
// Create implementation on demand
return new ClassLogic();
};
container.RegisterType<IClassLogic<string, string>>(
new InjectionFactory(c => {
return new ClassLogicProvider(classLogicFunc);
})
);
This should give you the desired Lazy creation when to implementation is needed.

CQRS with Dependency Injection

It should be a very quick question. I am trying to learn CQRS pattern and there is one thing which is not clear. There are two dispatchers: for commands and queries. Both of them need to have DI kernel injected in order to get appropriate handler. For example:
var handler = _resolver.Resolve<IQueryHandler<TQuery, TResult>>();
Isn't it violating the concept of DI that Resolve should never be used and everything should be injected with constructor/properties?
There is a bigger example: http://www.adamtibi.net/06-2013/implementing-a-cqrs-based-architecture-with-mvc-and-document-db
Please check out this method:
public void Dispatch<TParameter>(TParameter command) where TParameter : ICommand
{
var handler = _kernel.Get<ICommandHandler<TParameter>>();
handler.Execute(command);
}
I've found this solution on 3 different pages. Why is it done this way instead of creating a factory to map Query to QueryHandler?

If you consider the dispatcher to be a part of the infrastructure, calling Resolve() within it does not violate the DI concept you describe.
Handlers are generally thought of as entry points for logic pipelines (or threads, or however you want to think of them). This is similar to controllers in MVC, or the Main() method in a console application. So like these other constructs, the dispatcher is considered a top-level object in the dependency chain, and is thus a perfectly legitimate place to reference the container.
Edit
So the comments mention Composition Root (CR), which is a term I like but deliberately tried to avoid in this answer, as it tends to confuse people. Is the CR a specific class? An assembly? I tend to think of it more as a concept than a specific construct. It's the logical place in the application where object graphs are composed.
To clarify what I meant about controllers: the controllers would be the entry point, and (as #Zbigniew noted) the controller factory would be (part of) the CR. Similarly, handlers would be the entry point, and the dispatcher would be the CR. Handlers/Controllers would not have a reference to the container, but the Dispatcher/ControllerFactory would.

DI with command pattern

I have a service which acts to create and dispatch commands for execution. It can either write commands to queue for deferred processing, or execute them immediately.
For these purposes I have something like:
class MyService
{
private ICommandQueueWriter _commandQueueWriter;
private ICommandExecutor _commandExecutor;
public MyService(ICommandQueueWriter cqw, ICommandExecutor ce)
{
_commandQueueWriter = cqr;
_commandExecutor = ce;
}
public void DoSomething()
{
_commandQueueWriter.Write(new SomeCommand());
_commandExecutor.Execute(new SomeOtherCommand());
}
}
The service will deal with all kinds of commands. I have a series of ICommandHandler<> implementations which will be registered with a DI container.
My plan has a flaw currently: the ICommandExecutor implementation needs to have access to all of the ICommandHandler<> implementations. In fact, I guess the queued command execution will face the same problem: I'll grab the message later and have to look up the handler somehow.
So my options that I can see are:
Don't use ICommandExecutor as a dependency, just use ICommandHandler<>s directly. But I wanted the option of wrapping all command handler execution through a standard class - to catch exceptions in a consistent way, or manage execution in some other consistent way. I really like the option of having a consistent interface for immediate/deferred execution (either call Write or Execute)
Pass the DI container or root into ICommandExecutor and let it resolve commands. This seems to break the idea that there should be one call to compose an object graph with DI, and might 'hide' dependencies
Have the implementation of ICommandExecutor have all ICommandHandler<>s as a dependency to be injected - so it can pick the one it wants manually. However that doesn't seem ideal either, since all handlers on the system would be instantiated at that point
Is there are fourth option or do I need to bite the bullet with one of these compromises?

To me the use of both a ICommandQueueWriter and ICommandExecutor seems strange. Why should the consumer (MyService in your case) have to know that one command is queued, while another is executed directly. I think this should be transparent.
Have the implementation of ICommandExecutor have all
ICommandHandler<>s as a dependency to be injected
This will cause severe maintenance problems, because you will add new command handlers very regularly and this will cause you to have to update the command executor's constructor every time.
Although you could also inject a collection of command handlers, this would still force you to iterate the list every time you want to execute one to get the correct implementation. This will get slower over time, because you will add new command handlers regularly.
Pass the DI container or root into ICommandExecutor and let it resolve
commands. This seems to break the idea that there should be one call
to compose an object graph with DI, and might 'hide' dependencies
It might seem that you are applying the Service Locator anti-pattern if you do this, but this is only the case if the ICommandExecutor is part of the application code. The trick is to make the ICommandExecutor part of your Composition Root. This solves the problem because the composition root will already be very tightly coupled to your container.

Have the implementation of ICommandExecutor have all ICommandHandler<>s as a dependency to be injected - so it can pick the one it wants manually. However that doesn't seem ideal either, since all handlers on the system would be instantiated at that point
If you want to inject handlers, but don't want handlers to be instantiated at injection time, then
Inject into command executor a collection of lazy instantiated handlers with metadata containing command type.
Like,
IEnumerable(of Lazy(of ICommandHandler, ICommandHandlerMetadata))
where ICommandExecutorMetadata contains command type corresponding to command handler
public interface ICommandHandlerMetadata
readonly property CommandType as Type
end interface
In command executor transform the collection into a dictionary of pairs (Type, Lazy(of ICommandHandler, ICommandHandlerMetadata)), where Type is command type obtained from metadata through Lazy.Metadata.CommandType.
In CommandExecutor.Execute method lazy initiated command handler is obtained from the dictionary by command type. This operation is ultra fast. The actual CommandHandler is obtained through Lazy.Value.
Actual CommandHandler is instantiated only once and exactly when a corresponding command is executed.

Testable code: Attach event handler in constructor

as for my understanding, part of writing (unit-)testable code, a constructor should not do real work in constructor and only assigning fields. This worked pretty well so far. But I came across with a problem and I'm not sure what is the best way to solve it. See the code sample below.
class SomeClass
{
private IClassWithEvent classWithEvent;
public SomeClass(IClassWithEvent classWithEvent)
{
this.classWithEvent = classWithEvent;
// (1) attach event handler in ctor.
this.classWithEvent.Event += OnEvent;
}
public void ActivateEventHandling()
{
// (2) attach event handler in method
this.classWithEvent.Event += OnEvent;
}
private void OnEvent(object sender, EventArgs args)
{
}
}
For me option (1) sounds fine, but it the constructor should only assign fields. Option (2) feels a bit "too much".
Any help is appreciated.

A unit test would test SomeClass at most. Therefore you would typically mock classWithEvent. Using some kind of injection for classWithEvent in ctor is fine.
Just as Thomas Weller said wiring is field assignment.
Option 2 is actually bad IMHO. As if you omit a call to ActivateEventHandling you end up with a improperly initialized class and need to transport knowledge of the requirement to call ActivateEventHandling in comments or somehow else, which make the class harder to use and probably results in a class-usage that was not even tested by you, as you have called ActivateEventHandling and tested it but an uninformed user omitting the activation didn't, and you have certainly not tested your class when ActivateEventHandling was not called, right? :)
Edit: There may be alternative approaches here which are worth mentioning it
Depending on the paradigm it may be wise to avoid wiring events in the class at all. I need to relativize my comment on Stephen Byrne's answer.
Wiring can be regarded as context knowledge. The single responsibility principle says a class should do only one task. Furthermore a class can be used more versatile if it does not have a dependency to something else. A very loosely coupled system would provide many classes witch have events and handlers and do not know other classes.
The environment is then responsible for wiring all the classes together to connect events properly with handlers.
The environment would create the context in which the classes interact with each-other in a meaningful way.
A class in this case does therefore not know to whom it will be bound and it actually does not care. If it requires a value, it asks for it, whom it asks should be unknown to it. In that case there wouldn't even be an interface injected into the ctor to avoid a dependency. This concept is similar to neurons in a brain as they also emit messages to the environment and expect answer not knowing neighbouring neurons.
However I regard a dependency to an interface, if it is injected by some means of a dependency injection container just another paradigm and not less wrong.
The non trivial task of the environment to wire up all classes on start may lead to runtime errors (which are mitigated by a very good test coverage of functional and integration tests, which may be a hard task for large projects) and it gets very annoying if you need to wire dozens of classes and probably hundreds of events on startup manually.
While I agree that wiring in an environment and not in the class itself can be nice, it is not practical for large scale code.
Ralf Westphal (one of the founders of the clean code developer initiative (sorry german only)) has written a software that performs the wiring automatically in a concept called "event based components" (not necessarily coined by himself). It uses naming conventions and signature matching with reflection to bind events and handlers together.

Wiring events is field assignment (because delegates are nothing but simple reference variables that point to methods).
So option(1) is fine.

The point of constructor is not to "assign fields". It is to establish invariants of your object, i. e. something that never changes during its lifetime.
So if in other methods of class you depend on being always subscribed to some object, you'd better do it in the constructor.
On the other hand, if subscriptions come and go (probably not the case here), you can move this code to another method.

The single responsibility principle dictates that that wiring should be avoided. Your class should not care how, or where from it receives data. It would make sense to rename OnEvent method to something more meaningful, and make it public.
Then some other class (bootstrapper, configurator, whatever) should be responsible for the wiring. Your class should only be responsible for what happens when a new data come's in.
Pseudo code:
public interface IEventProvider //your IClassWithEvent
{
Event MyEvent...
}
public class EventResponder : IEventResponder
{
public void OnEvent(object sender, EventArgs args){...}
}
public class Boostrapper
{
public void WireEvent(IEventProvider eventProvider, IEventResponder eventResponder)
{
eventProvider>event += eventResponder.OnEvent;
}
}
Note, the above is pseudo code, and it's only for the purpose to describe the idea.
How your bootstrapper actually is implemented depends on many things. It can be your "main" method, or your global.asax, or whatever you have in place to actually configure and prepare your application.
The idea is, that whatever is responsible to prepare the application to run, should compose it, not the classes themselves, as they should be as single purpose as possible, and should not care too much about how and where they are used.

Dependency Injection and development productivity

Abstract
For the past few months I have been programming a light weight, C# based game engine with API abstraction and entity/component/scripting system. The whole idea of it is to ease the game development process in XNA, SlimDX and such, by providing architecture similar to that of the Unity engine.
Design challenges
As most game developers know, there are a lot of different services you need to access throughout your code. Many developers resort to using global static instances of e.g. a Render manager(or a composer), a Scene, Graphicsdevice(DX), Logger, Input state, Viewport, Window and so on. There are some alternative approaches to the global static instances/ singletons. One is to give each class an instance of the classes it needs access to, either through a constructor or constructor/property dependency injection(DI), another is to use a global service locator, like StructureMap's ObjectFactory where the service locator is usually configured as an IoC container.
Dependency Injection
I chose to go the DI way for many reasons. The most obvious one being testability, by programming against interfaces and have all the dependencies of every class provided to them through a constructor, those classes are easily tested since the test container can instantiate the required services, or the mocks of them, and feed into every class to be tested. Another reason for doing DI/IoC was, believe it or not, to increase the readability of the code. No more huge initialization process of instantiating all the different services and manually instantiating classes with references to the required services. Configuring the Kernel(NInject)/Registry(StructureMap) conveniently gives a single point of configuration for the engine/game, where service implementations are picked and configured.
My problems
I often feel like I am creating interfaces for interfaces sake
My productivity has gone down dramatically since all I do is worry about how to do things the DI-way, instead of the quick and simple global static way.
In some cases, e.g. when instantiating new Entities on runtime, one needs access to the IoC container / kernel to create the instance. This creates a dependency on the IoC container itself (ObjectFactory in SM, an instance of the kernel in Ninject), which really goes against the reason for using one in the first place. How can this be resolved? Abstract factories come to mind, but that just further complicates the code.
Depending on service requirements, some classes' constructors can get very large, which will make the class completely useless in other contexts where and if an IoC is not used.
Basically doing DI/IoC dramatically slows down my productivity and in some cases further complicates the code and architecture. Therefore I am uncertain of whether it is a path I should follow, or just give up and do things the old fashioned way. I am not looking for a single answer saying what I should or shouldn't do but a discussion on if using DI is worth it in the long run as opposed to using the global static/singleton way, possible pros and cons I have overlooked and possible solutions to my problems listed above, when dealing with DI.

Should you go back to the old-fashioned way?
My answer in short is no. DI has numerous benefits for all the reasons you mentioned.
I often feel like I am creating interfaces for interfaces sake
If you are doing this you might be violating the
Reused Abstractions Principle (RAP)
Depending on service requirements, some classes' constructors can get
very large, which will make the class completely useless in other
contexts where and if an IoC is not used.
If your classes constructors are too large and complex, this is the best way to show you that you are violating a very important other principle:
Single Reponsibility Principle. In this case it is time to extract and refactor your code into different classes, the number of dependencies suggested is around 4.
In order to do DI you don't have to have an interface, DI is just the way you get your dependencies into your object. Creating interfaces might be a needed way to be able to substitute a dependency for testing purposes.
Unless the object of the dependency is:
Easy to isolate
Doesn't talk to external subsystems (file system
etc)
You can create your dependency as an Abstract class, or any class where the methods you'd like to substitute are virtual. However interfaces do create the best de-coupled way of an dependency.
In some cases, e.g. when instantiating new Entities on runtime, one
needs access to the IoC container / kernel to create the instance.
This creates a dependency on the IoC container itself (ObjectFactory
in SM, an instance of the kernel in Ninject), which really goes
against the reason for using one in the first place. How can this be
resolved? Abstract factories come to mind, but that just further
complicates the code.
As far as a dependency to the IOC container, you should never have a dependency to it in your client classes.
And they don't have to.
In order to first use dependency injection properly is to understand the concept of the Composition Root. This is the only place where your container should be referenced. At this point your entire object graph is constructed. Once you understand this you will realize you never need the container in your clients. As each client just gets its dependency injected.
There are also MANY other creational patterns you can follow to make construction easier:
Say you want to construct an object with many dependencies like this:
new SomeBusinessObject(
new SomethingChangedNotificationService(new EmailErrorHandler()),
new EmailErrorHandler(),
new MyDao(new EmailErrorHandler()));
You can create a concrete factory that knows how to construct this:
public static class SomeBusinessObjectFactory
{
public static SomeBusinessObject Create()
{
return new SomeBusinessObject(
new SomethingChangedNotificationService(new EmailErrorHandler()),
new EmailErrorHandler(),
new MyDao(new EmailErrorHandler()));
}
}
And then use it like this:
SomeBusinessObject bo = SomeBusinessObjectFactory.Create();
You can also use poor mans di and create a constructor that takes no arguments at all:
public SomeBusinessObject()
{
var errorHandler = new EmailErrorHandler();
var dao = new MyDao(errorHandler);
var notificationService = new SomethingChangedNotificationService(errorHandler);
Initialize(notificationService, errorHandler, dao);
}
protected void Initialize(
INotificationService notifcationService,
IErrorHandler errorHandler,
MyDao dao)
{
this._NotificationService = notifcationService;
this._ErrorHandler = errorHandler;
this._Dao = dao;
}
Then it just seems like it used to work:
SomeBusinessObject bo = new SomeBusinessObject();
Using Poor Man's DI is considered bad when your default implementations are in external third party libraries, but less bad when you have a good default implementation.
Then obviously there are all the DI containers, Object builders and other patterns.
So all you need is to think of a good creational pattern for your object. Your object itself should not care how to create the dependencies, in fact it makes them MORE complicated and causes them to mix 2 kinds of logic. So I don't beleive using DI should have loss of productivity.
There are some special cases where your object cannot just get a single instance injected to it. Where the lifetime is generally shorter and on-the-fly instances are required. In this case you should inject the Factory into the object as a dependency:
public interface IDataAccessFactory
{
TDao Create<TDao>();
}
As you can notice this version is generic because it can make use of an IoC container to create various types (Take note though the IoC container is still not visible to my client).
public class ConcreteDataAccessFactory : IDataAccessFactory
{
private readonly IocContainer _Container;
public ConcreteDataAccessFactory(IocContainer container)
{
this._Container = container;
}
public TDao Create<TDao>()
{
return (TDao)Activator.CreateInstance(typeof(TDao),
this._Container.Resolve<Dependency1>(),
this._Container.Resolve<Dependency2>())
}
}
Notice I used activator even though I had an Ioc container, this is important to note that the factory needs to construct a new instance of object and not just assume the container will provide a new instance as the object may be registered with different lifetimes (Singleton, ThreadLocal, etc). However depending on which container you are using some can generate these factories for you. However if you are certain the object is registered with Transient lifetime, you can simply resolve it.
EDIT: Adding class with Abstract Factory dependency:
public class SomeOtherBusinessObject
{
private IDataAccessFactory _DataAccessFactory;
public SomeOtherBusinessObject(
IDataAccessFactory dataAccessFactory,
INotificationService notifcationService,
IErrorHandler errorHandler)
{
this._DataAccessFactory = dataAccessFactory;
}
public void DoSomething()
{
for (int i = 0; i < 10; i++)
{
using (var dao = this._DataAccessFactory.Create<MyDao>())
{
// work with dao
// Console.WriteLine(
// "Working with dao: " + dao.GetHashCode().ToString());
}
}
}
}
Basically doing DI/IoC dramatically slows down my productivity and in
some cases further complicates the code and architecture
Mark Seeman wrote an awesome blog on the subject, and answered the question:
My first reaction to that sort of question is: you say loosely coupled code is harder to understand. Harder than what?
Loose Coupling and the Big Picture
EDIT: Finally I'd like to point out that not every object and dependency needs or should be dependency injected, first consider if what you are using is actually considered a dependency:
What are dependencies?
Application Configuration
System Resources (Clock)
Third Party Libraries
Database
WCF/Network Services
External Systems (File/Email)
Any of the above objects or collaborators can be out of your control and cause side effects and difference in behavior and make it hard to test. These are the times to consider an Abstraction (Class/Interface) and use DI.
What are not dependencies, doesn't really need DI?
List<T>
MemoryStream
Strings/Primitives
Leaf Objects/Dto's
Objects such as the above can simply be instantiated where needed using the new keyword. I would not suggest using DI for such simple objects unless there are specific reasons. Consider the question if the object is under your full control and doesn't cause any additional object graphs or side effects in behavior (at least anything that you want to change/control the behavior of or test). In this case simply new them up.
I have posted a lot of links to Mark Seeman's posts, but I really recommend you read his book and blog posts.