I seem to need this a lot.
Let's say I have a class with constructor taking several arguments. Some of these can be resolved by registering components. But the rest are instances created during runtime (e.g. fetching an entity from database).
Can Autofac deal with these situations in a nice way? Or is my design sub-optimal?
To clarify, I have classes that have constructors like this:
public MyClass(IService1 service1, IService2 service2, Data1 data1, Data2 data2)
{
//...
}
And I would like to do something like this:
container.Resolve<MyClass>(data1, data2);
You can handle this elegantly by registering a factory method in the Autofac container. You resolve the factory method, and then use it to create instances with your runtime dependencies. You can do this yourself by registering and resolving delegates or custom factory types. However, Autofac has explicit support for delegate factories.
There is not enough information to comment on your design. I'll leave that to you :)
I would say your design is sub optimal.
You seem to be mixing to things. Dependency injection (using a container) should mainly be used for injecting service components into other components. Don't inject thing like entities, because it is not up to the container to manage their lifetime. Rather, inject a service that can manage entities for you, such as a repository. Although topic of discussion, I would neither inject a unit of work, but rather a factory for creating unit of works. This way your application manages the lifetime of the unit of work explicitly.
Related
I have a situation where i am currently using constructor dependency injection for a small module that fits inside a larger web framework.
Its working fine but now there is a new class being introduced that requires 2 objects passed to it. But, 1 of the objects requires a lot of work to get set up - essentially it invovles around 4 method calls which create other objects in order to get it into a working state ready to be passed to my object.
My dilemna is that constructor injection is no use due to the work involved, but introducing a ioc container is way overboard, especially for this 1 off use case.
So, how should this be handled? Is there some sort of solution that sits in the middle of these two options?
You've effectively got four five choices:
Poor Man's DI (create objects manually and pass to constructors)
IoC container
Factory method
Abstract factory
Builder (thanks, Mark Seemann!)
I usually start off with an IoC container, but I do a lot of DI. (I've seen too many tightly-coupled codebases.)
If you don't want to introduce an IoC container, I'd lean towards Poor Man's DI.
If you're working in any object-oriented language (not just C#), I recommend reading the book Dependency Injection in .NET. It covers the patterns and anti-patterns in detail.
1 of the objects requires a lot of work to get set up - essentially it invovles around 4 method calls which create other objects in order to get it into a working state ready to be passed to my object.
OK, then create the object and pass the completely initialized object to the constructor, in which it needs to go.
Creating that object sounds like a job for a Builder or Factory.
My dilemna is that constructor injection is no use due to the work
involved,
I prefer Constructor Injection and see no reasons to avoid it.
Using modern IoC frameworks you can specify creation logic that involves "a lot of work to get set up" via factory/ factory method.
No matter how many steps are needed to build an instance of IMyService, you can simply use a constructor dependency to inject it.
Castle Windsor
container.AddFacility<FactorySupportFacility>()
.Register(
Component.For<IMyFactory>().ImplementedBy<MyFactory>(),
Component.For<IMyService>()
.UsingFactoryMethod(k => k.Resolve<IMyFactory>().Create())
);
Unity
var container = new UnityContainer();
container.RegisterType<IMyFactory, MyFactory>();
container.RegisterType<IMyService>(
new InjectionFactory(c => c.Resolve<IMyFactory>().Create()));
I'm seriously start thinking that usage of IoC container provokes to create overdesigned solutions (at least it provokes me to try to use various unnecessary features:).
It's the time to synchronize my "IoC" antipatterns list with community one's..
My short experience tell that it is absolutely enough to call Resolve method once per application at startup to resolve some infrastructure singletons and initiate with them "transient object's factory" that could produce new "smaller life time grain factories" . Even to make those factories thread safe (e.g. create one instance per thread) is so easy to achieve by adding 10 code lines into factory... Still those factories are much more simpler then "library's integration with IoC tool". Interception? Just create your own wrappers... Life time managers / dependency strategies/ parent containers? Call the Resolve only once at bootstrapper and you won't think about that.
Could you help me to understand why developers call Resolve several times on different application layers (by passing container or by passing delegate to container) and then have a lot of things to think about? I really worry that I miss something.
Some kind of IoC are anti-patterns or may be in some cases. For example the service locator antipattern. But if you are using constructor injection at the beginning of your application - and only there - then it should not lead to an anti-pattern.
Injecting a DI container interface in a class is a wrong use of constructor injection. If DI is not part of the business logic of your class it should not know or depend on DI container nor should it depend on IKitchen. It's only fine to inject your DI container in some kind of helper or service working in conjunction with your dependency injection container, because it's purpose is to work with or around DI container. The examples in the links you give are misuse of IoC. It does not mean that IoC in general is an anti-pattern.
I think the correct question would be "Can constructor injection be an anti-pattern?". So far I've never faced any situation or seen any example where it was so I would say "no", until I face such a situation.
When it was not clear to me how to use an IoC container, I decided to stop using it, because I thought was just an overcomplication over the simple dependency injection.
It is true though that even without IoC is possible to fall in the over-injection cases.
A while ago I read some posts from the author of ninject that opened my mind.
As you already know the injector should be used only inside the context root. However, in order to avoid over-injections, I decided to introduce an exception of the rule for injected factories.
In my framework, factories (and only factories) can use the injector container. Factories are binded in the container in the context root and therefore can be injected. Factories become valid dependencies and are used to create new objects inside other objects, using the injector container to facilitate dependencies injection.
Read This
Clearly something wrong. New library should not bring additional complex code.
I've found somebody who possibly could understand me :)
Constructor over-injection anti-pattern
Other antipattern in my eyes is pushing the initialization of container "deeper" then actual bootsrapper.
For example Unity and WCF recommendations
Bootstrapper in wcf app is the service constructor, then just put container initialization to constructor. I do not understand reasons to recommend to go for programming wcf sevice behaiviors and custome sevice host factory: if you want to have "IoC container free" bootstrapper - it is absurd, if you need to have "IoC container free" service contract implementation - just create second "IoC container free" service contract implementation.
I am using Castle Windsor.
I have two component types where the implementation can be selected at runtime on a GUI. To handle this, I am resolving them by name. To handle resolving them by name, I am using the Typed Factory Facility.
One of the component types depends on the other. To handle the dependency, I am passing the argument as a factory method/constructor parameter argument.
Here is a redacted and abridged version of this factory interface:
public interface IModelFactory
{
IMyDomainCommandFactory GetFooCommandFactory();
IMyDomainCommandFactory GetBarCommandFactory();
IMyDomainStrategy GetCreateSpecificSizeStrategy(int size, IMyDomainCommandFactory commandFactory);
IMyDomainStrategy GetCreateUntilFailureStrategy(IMyDomainCommandFactory commandFactory);
}
Note that I am using my own implementations for IMyDomainCommandFactory, rather than using the Typed Factory facility. Those factories have intentionally complex behavior, and the facility doesn't suit their needs.
The problem I am noticing is that if I register my strategy components with a singleton lifestyle, I always get back the same instance, even if I pass different arguments to the getter.
In my opinion, this goes against the Principal of Least Astonishment, but maybe other people have a different opinion :) Should this be considered a bug?
If not, is there a clean way to get the container or factory to create only one instance per argument combination?
Depending how you look at it, but certainly instance per combination of parameters can't be called a singleton so I say it would go against PoLA if Windsor did implement the behavior you'd expect.
If you want it, you need a custom, non-singleton lifestyle.
So I have a layered application that I am adding a WCF service interface on top of. The service is simply a facade with all of our business logic already existing in Business Objects (BOs) within the Business Logic Layer (BLL) which is a class library. Within the BLL we use constructor injection to inject dependencies into the BOs. This is all working with good unit testing, etc. On to the problem...
Ordinarily I'd simply create a set of Request/Response objects as DataContracts for each service method with the appropriate properties for the operation. If the operation required one of our "entities" to be passed either to or from the method, I'd simply define a property of that type and everything would be fine (all of our BOs are serializable). However when one of these "entities" is passed into a service method, WCF deserializes the object without ever invoking the constructors we've defined and, as a result, the dependencies don't resolve.
Let's use the case of a service method called CreateSomething. I'd normally define this as a service operation with a signature like:
CreateSomethingResponse CreateSomething(CreateSomethingRequest request);
CreateSomethingRequest would be a DataContract and have amongst its properties a property of type Something that represented the "entity" being passed into the service. Something, in this case, is a business object that expects to receive an instance of the ISomethingRepository interface from the DI container when instantiated - which, as I said above, does not happen when WCF deserializes the object on the server.
Option #2 is to remove the Something property from the DataContract and define each of the properties explicitly in my DataContract then inside my service method, create a new instance of the Something class, letting the container inject the dependency, then map the property values from the DataContract object into the BO. And I can certainly do that but I am concerned about now having two places to make changes if, say, I want to add a property to the Something type. And, with a lot of properties, there's a lot of code duplication.
Has anyone crossed this bridge and, if so, can you share your thoughts and how you have or would approach this situation in your own applications? Thx!!!
There are two answers on your problem:
First: Do not send your entities and use data transfer objects instead. Your entities are business objects with its logic and data. The logic of business objects is most probably used to control the data. So let the business object control its data in business layer and exchange only dummy crates.
Second: If you don't want to follow the first approach, check documentation of your IoC container. There are ususally two methods for resolving dependencies. For example Unity offers:
Resolve - builds new instance and injects all dependencies (necessary for constructor injection)
BuildUp - takes existing instance and resolves all property dependencies. This should be your choice.
Thanks, Ladislav, for your answer as you confirmed what was already in my head.
What I ended up doing was to change my approach a little. I realized that my use of a business object, per se, was overkill and unnecessary. Or perhaps, just misdirected. When evaluating my requirements, I realized that I could "simplify" my approach and make everything work. By taking each logical layer in my application and looking at what data needed to pass between the layers, I found a design that works.
First, for my business logic layer, instead of a business object, I implemented a Unit of Work object: SomethingManager. SomethingManager is tied to my root Something entity so that any action I want to perform on or with Something is done through the SomethingManager. This includes methods like GetById, GetAll, Save and Delete.
The SomethingManager class accepts two objects in its constructor: an IValidator<Something> and an ISomethingRepository. These will be injected in by the IoC container. The former lets me perform all of the necessary validation using whatever framework we chose (initially the Validation Application Block) and the latter gives me persistance ignorance and abstracts the use of Linq-to-SQL today and makes upgrading to EF4 much easier later on.
For my service layer, I've wired the IoC container (Unity in this case) into WCF so the service instance is created by the container. This allows me to inject an instance of ISomethingManager into my service. Using the interface, I can break the dependency and easily unit test the service class. Plus, because the container is injecting the ISomethingManager instance, it is constructing it and will automatically resolve it's dependencies.
I then created DataContracts to represent how the data should appear when transferred across the wire via the service. Each Request/Response object contains these DataContracts as DataMembers rather than referencing my entity classes (or BOs) directly. It is up to the service method to map the data coming from or going to the Business Logic Layer (via ISomethingManager) - using AutoMapper to make this clean and efficient.
Back in the data layer, I've simply extended the generated entity classes by defining a partial class that implements the desired interface from the BLL. For instance, the Something L2S entity has a partial defined that implements ISomething. And ISomething is what the SomethingManager (and ISomethingManager interface) and ISomethingRepository work with making it very easy to query the database and pass the L2S entity up the chain for the service layer to consume and pass on (without the service layer having any knowledge or dependency on the L2S implementation).
I appreciate any comment, questions, criticisms or suggestions anyone has on this approach.
It was recommended to me that, when using an IOC container, I should change this:
class Foobar: IFoobar, IDisposable {};
Into this:
interface IFoobar: IDisposable{};
class Foobar : IFoobar{};
I'm wondering if this is ok, or if it solves one problem and creates another. It certainly solves the problem where I badly want to do this:
using( IFoobar = myContainer.Resolve<IFoobar>() )
{ ... }
And now I know that any substitute won't cause a run-time error.
On the other hand, now all my mock objects must handle IDisposable too. Am I right that most any mocking framework handles this easily? If yes, then perhaps this is a non-issue.
Or is it? Is there another hidden gotcha I should watch for? It certainly occurs to me that if I were using an IOC container not for unit tests / mocking, but for true service independence, then this might be a problem because perhaps only one of my swappable services actually deals with unmanaged resources (and now I'm having to implement empty "IDispose" operations in these other services).
Even this latter issue I suppose I could live with, for the sake of gaining the ability to employ the "using" statement as I demoed above. But am I following a popular convention, or am I missing an entirely different and better solution?
Deriving an interface from IDisposable is in my opinion a design smell that indicates a Leaky Abstraction. As Nicholas Blumhardt put it:
an interface [...] generally shouldn't be disposable. There's no way for the one defining an interface to foresee all possible implementations of it - you can always come up with a disposable implementation of practically any interface.
Consider why you want to add IDisposable to your interface. It's probably because you have a particular implementation in mind. Hence, the implementation leaks into the abstraction.
An DI Container worth its salt should know when it creates an instance of a disposable type. When you subsequently ask the container to release an object graph, it should automatically dispose the disposable components (if their time is up according to their lifestyles).
I know that at least Castle Windsor and Autofac does this.
So in your case, you should keep your type like this:
class Foobar: IFoobar, IDisposable {};
You may find Nicholas Blumhardt's post The Relationship Zoo interesting as well - particularly the discussion about Owned<T>.