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