How does proper use of IoC containers help you to avoid using factories?

Question

Many IoC containers have a feature of 'auto factories', which generate an implementation of an abstract factory based on its interface. However, it's often a second-class citizen: StructureMap declares only a basic support for the feature, while Simple Injector's author has deliberately omitted auto factories from the library claiming that when applying Dependency Injection correctly, the need for using factories is minimized. This not the only place where I came across a similar view.

However, to me factories seem to be an indispensable element of design when using IoC and writing domain models. Say, a simple made-up example could be:

class Order
{
    private ITaxProvider _taxProvider;

    public decimal Quantity { get; set; }
    public decimal PricePerUnit { get; set; }
    public decimal Cost { get; set; }

    public Order(ITaxProvider taxProvider)
    {
        _taxProvider = taxProvider;
    }

    public decimal GetProfit()
    {
        // Don't nitpick on this example, please, it's just to show some
        // kind of domain object that depends on some kind of service,
        // but also has some logic of its own.
        decimal grossProfit = Quantity * PricePerUnit - Cost;
        decimal netProfit = grossProfit * (1.0m - _taxProvider.GetTaxRate());
        return netProfit;
    }
}

In this case, every time I create an Order, say, inside an MVC controller, I will need to use a factory. Eventually, this will most likely be true about any domain object. Even if they may not have any dependencies right now, it is very likely that somebody at some point will request some functionality to behave differently depending on a configuration value, or that some code will be refactored out to separate classes, which may then be decoupled using DI to be testable in separation.

So I am almost willing to roll out factories to take control over initialization of every single domain object. But more experienced developers than myself are saying that I shouldn't need to use factories very often with IoC containers. What should I change in my code's design to make the factories unnecessary?

To understand Steven's reasons for excluding factories from Simple Injector you should start at the beginning: [here](https://cuttingedge.it/blogs/steven/pivot/entry.php?id=91) — qujck, Feb 10 '16 at 22:07
The argument goes against factories that return other components, not against any type of factories, such as those that return domain objects or other value types. Factories that return components are especially the type of factories that 'auto factory' features of containers provide. — Steven, Feb 11 '16 at 00:34
So your TaxProvider is the factory here? In that sense repositories are factories too. There's nothing wrong with them. — Steven, Feb 11 '16 at 11:37
@Steven No, I didn't show the factory, the factory will be used to create the instances of `Order`. `ITaxProvider` is a dependency which will be provided by the IoC container. Which is why a factory is needed. — kamilk, Feb 11 '16 at 19:15
An abstraction that allows creating entities isn't called a factory; it's a repository. The error you are making however is that you inject components in the entities constructor. This is considered to be bad. Your IoC container should not be tasked with creating entities; its job is to construct components. — Steven, Feb 12 '16 at 02:36

Ric .Net · Accepted Answer · 2016-02-12T08:30:15.843

In my opinion a domain model should never ever contain dependencies. They should be as close a possible to a POCO. There just messages in my system which can be easily shipped from class to class using method injection.

These patterns are described here and here, as the comments already suggested.

If we would make the Order a POCO, how would we calculate the profit? By making a service which does nothing more than calculating the profit:

public class ProfitCalculator
{
    private readonly ITaxProvider taxProvider;

    public ProfitCalculator(ITaxProvider taxProvider)
    {
        this.taxProvider = taxProvider;
    }

    public decimal GetProfit(Order order)
    {
        decimal grossProfit = order.Quantity * order.PricePerUnit - order.Cost;
        decimal netProfit = grossProfit * (1.0m - this.taxProvider.GetTaxRate());
        return netProfit;
    }
}

Assuming ITaxProvider could be a singleton, ProfitCalculator could be a singleton also. And order would be just a plain object:

class Order
{
    public decimal Quantity { get; set; }
    public decimal PricePerUnit { get; set; }
    public decimal Cost { get; set; }
}

This would remove the need for a factory completely. Using the message based patterns as described in the referenced blogpost will make your life far easier.

Update:

As Steven comment suggests this is not the only solution. Instead of creating a calculator class you could also define a method which takes the dependency as a parameter. I prefer to implement such a method as an extension method like this:

public static class DomainExtensions
{
    public static decimal GetProfit(this Order order, ITaxProvider taxProvider)
    {
        decimal grossProfit = order.Quantity * order.PricePerUnit - order.Cost;
        decimal netProfit = grossProfit * (1.0m - taxProvider.GetTaxRate());
        return netProfit;
    }
}

It's okay for domain objects to depend on components, but instead of injecting them in the constructor, these dependencies should simply be passed as method arguments, as in: `GetProfit(ITaxProvider provider)`. When using the suggested patterns however, the real domain objects will be your command objects. — Steven, Feb 12 '16 at 02:45

How does proper use of IoC containers help you to avoid using factories?

1 Answers1