1

I am using Dependency Injection. Say that I has an OrderService class like this:

public class OrderService{
    public OrderService(
        IOrderValidator validator
        , IOrderRepository repository
        , IOrderNotificator notificator){
        //assign global fields
    }

    public void SubmitOrder(Order ord){
        if(validator.IsOrderValid(ord)){
            repository.InsertNew(ord);
            notificator.Notify(ord);
        }
    }
}

Now I wonder to create a facade class for example TypeAOrderService, as inherited by OrderService, with components declared in constructor such as:

public class TypeAOrderService : OrderService{
    public TypeAOrderService() : base(
        new OrderValidator(),
        new OrderRepository(),
        new OrderNotificator()) { }
}

(Note that the implementation with injected component complexity is not important here, an adapter pattern also acceptable to replace inheritance though).

There may be downsides here because we don't define the dependency at composition root. However I wonder whether it is acceptable in some situation. Especially at framework component when it is rather weird to use the framework by accessing the DI Container and resolve it yourself.

Update:

As mentioned in comment, currently I don't use any IOC container. My perspective is, it is weird to use IOC container in Framework, since it will means that every application uses the framework will need to use IOC container. If my perspective is wrong, feel free to correct me.

What I am refering as the framework example is such as System.Windows.Forms.Form where I don't use any IOC container and don't determine the dependency.

Fendy
  • 4,565
  • 1
  • 20
  • 25
  • Hello Fendy, Are you trying to use only dependency injection, or are you also trying to use an IOC container. IMHO the approach you are taking will work, however if you are using an IOC container (like windsor) i think you are better of creating an installer for you component. Maybe this post can help you http://kozmic.net/2010/08/10/ioc-patterns-ndash-partitioning-registration/ – Marwijn May 16 '13 at 10:26
  • @Marwijn Currently I don't use any IOC container. My perspective is, it is weird to use IOC container in Framework, since it will means that every application uses the framework will need to use IOC container (also please explain if my perspective is wrong). I am refering the framework example such as `System.Windows.Forms.Form` – Fendy May 16 '13 at 10:38
  • If you don't want to use an IOC container, and you seem to have a legit reason todo so, I think your approach is fine. In that case OrderValidator, OrderRepository and OrderNotificator maybe even private classes of your Assembly. – Marwijn May 16 '13 at 10:42
  • @Marwijn I have updated the question about IOC container. It seems that your statement makes sense. Can you please explain it by answering the question? – Fendy May 16 '13 at 10:52
  • Let me try to answer it tomorrow then I can phrase it a better better then in these short comments. – Marwijn May 16 '13 at 13:00
  • Could you give me some hints about what exactly you mean by framework? I don't really get what you mean with : What I am refering as the framework example is such as System.Windows.Forms.Form where I don't use any IOC container and don't determine the dependency... – Marc May 17 '13 at 07:10
  • @Marc What I mean is when using framework component like `System.Windows.Forms.Form`, I don't need to use IOC container, and don't need to inject dependencies there. Is there a bad practice at reality? – Fendy May 17 '13 at 07:36

1 Answers1

2

Regarding whether to use IoC, I think it's fine to use IoC within a framework library. It just means your framework has its own Container and Composition Root that are entirely hidden from any of its consumers. You can create Facade classes that make it easy to consume. Something like this:

public class OrderServiceFacade
{
    private readonly IOrderService OrderService;

    public class OrderServiceFacade()
    {
        this.OrderService = ContainerWrapper.Container.Resolve<IOrderService>();
    }

    public void SubmitOrder(Order ord) {
        OrderService.SubmitOrder(ord);
    }
}

Where ContainerWrapper is your Composition Root, a wrapper around the DI Container.

internal class ContainerWrapper
{
    private Container _Container;
    public Container Container
    {
        if(_Container == null)
        {
            //initialize it
        }
        return _Container;
    }
}

Of course you would need OrderService and TypeAOrderService to inherit from a new IOrderService interface. This also decouples your TypeAOrderService from your OrderService, as it can then take interfaces in its constructor rather than directly instantiate particular implementations. In the event you actually need TypeAOrderService to call methods on OrderService, you can use the Decorator Pattern and have TypeAOrderService take IOrderService as an additional dependency.

Facio Ratio
  • 3,373
  • 1
  • 16
  • 18