Is this a typical use case for IOC?

Question

My current application allows users to define custom web forms through a set of admin screens. it\'s essentially an EAV type application. As such, I can\'t hard code HTML or AS

Answer 1

Unless I want to end up with an explosion of methods (OpenFormViewingScenario1, OpenFormViewingScenario2, etc).

You can not remove the inherent complexity of the requirements. One way or another, you will need to detect the use case and act accordingly.

You can list all possible combinations or try to factor out the processing intelligently -- if it's possible. For instance, if due to the very nature of the requirement there are N * M = X possibilities, then having an exhaustive listing of X methods is indeed not good. You should factor so has to create the X possible forms from a composition of the N and M cases.

Without knowing the exact requirement it's hard to say. Then there are many possible way to factor such a composition, e.g. Decorator, ChainOfResponsability, Filter, etc. These are all ways to compose complex logic.

Namely, the UI, which had been living in ignorant bliss about the implementation details of OpenFormForViewing, must possess knowledge of and create an instance of IFormViewCreator.

The presentation should be handed out a form created somewhere else, so as to remain agnostic from the form creation. The form will however need to be assembled/created somewhere.

In MVC, such logic goes in the controller which would update the model/form and dispatch to the correct view/rendering. The same can be done with ASP.NET

Answer 2

As I understand the question, you need to modify the Form before sending it off to the UI layer. That sounds to me like a Decorator would be in place. Keep the old IFormService interface without the IFormViewCreator.

You can now create one or more Decorating FormService(s) that implement the desired filtering or modification.

public class MyDecoratingFormService : IFormService
{
    private readonly IFormService formService;

    public MyDecoratingFormService(IFormService formService)
    {
        if(formService == null)
        {
            throw new ArgumentNullException("formService");
        }

        this.formService = formService;
    }

    public Form OpenFormForEditing(int formId)
    {
        var form = this.formService.OpenFormForEditing(formId);
        return this.TransformForm(form);
    }   

    public Form OpenFormForViewing(int formId)
    {
        var form = this.formService.OpenFormForViewing(formId);
        return this.TransformForm(form);
    }

    public Form TransformForm(Form form)
    {
        // Implement transformation/filtering/modification here
    }
}

You can now decorate your original IFormService implementation with one or more of such Decorators.

IFormService formService = new MyDecoratingFormService(new MyFormService());

You can wrap as many Decorators (each with their own responsibility) around each other as you'd like.

There's no explicit need for a DI Container to do this, but it fits nicely with other DI patterns. I use Decorator all the time :)