Bil Simser
unread,May 29, 2008, 8:01:51 AM5/29/08Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to xeva
I'm trying to figure out a good way to use a composite view without
having a presenter need dozens of interfaces injected into it.
For example in the BankTeller sample ShellContext launches the
LoginPresenter which in turn starts the ShellPresenter. Let's say the
ShellPresenter has a menuing system that has 10 options. Each option
would start a new presenter.
So you might have a composite presenter that would have callbacks like
this:
interface IShellCallbacks : IViewCallbacks
{
void MenuOption1(); // it wouldn't be called this but something more
business-like
void MenuOption2();
etc.
}
Then in the view you would wire up the callback to a response to a
menu click and call the implementation in the presenter.
The problem lies in the fact that if I try to locate the presenter for
each menu option, I have a method like this in my presenter:
void MenuOption1()
{
// create window adapter via window manager
IMenuOption1Presenter presenter =
Locator.Resolve<IMenuOption1Presenter>();
presenter.DisplayIn(adapter);
presenter.Start();
}
Problem is that I can't test this presenter (the one calling all the
separate presenters) because it has the Locator call which is static
(and requires castle to be initialized, etc.)
I can get around this by injecting my presenters and the manager into
the ShellPresenter (or whatever presenter is going to host the
callbacks that are linked to the UI elements):
public ShellPresenter(
IMenuOption1Presenter menuOption1Presenter,
IMenuOption2Presenter menuOption2Presenter,
etc.
IWindowManager windowManager)
Then I only have to call Locator.Resolve<IShellPresenter>() in
ShellContext and IoC will resolve all the dependencies. However this
is super ugly and unmaintainable once you get enough presenters that
the composite view will start.
You could use the ToolSelected(string key) idea, but then you still
run into the problem of that ToolSelected method having to call the
Locator.Resolve method to find the appropriate presenter and you're
back at the non-testable state (or need castle to be initialized in
your tests).
Looking for ideas.