Composite View Architecture Advice

Topics: Prism v2 - Silverlight 2
Apr 16, 2009 at 7:15 PM
Edited Apr 16, 2009 at 7:18 PM
Hello,

i'm working on a Composite Silverlight application and i've reached a point where i need some advice on the architecture i'm designing.

Here's the simplified scenario:

The SL application loads two modules A and B. 
Each module has a view of its own, view A and view B, respectively.
Each view has a presentation model with business data and a controller of its own.

I want to inject both views in the same region, but this views will be visible interchangeably.

The application loads with View A active and visible. 
It has a button. If i press it, View A disappears, and gives place to View B.

View B has a button, if i click it, View B closes and View A appears. 

I've implemented this using the controller command delegates to publish an event subscribed by the other controller.
When handling the event, the controller removes the view from the region.

Questions:

* Should i use a controller, that controls both controllers ? I mean, a higher lever controller. The actual implementation is becoming kind of limited.. However i don't want to break the pattern.
* If want to implement an animation, where both views are partially seen at some point, like one slidding one over the other, should i create a composite view with these views, instead of doing that on the shell ?

Thank you,
F









Apr 17, 2009 at 8:53 PM

Hi F,

       

In my personal opinion, and without knowing the complexity and specifics of your application, I would not use a higher controller. I will try to explain what I have in mind. These steps are not the only things that could be done, but just the main ones:

1.       ViewA Button (ButtonA) is clicked.

2.       ControllerA finds out ButtonA has been clicked. This can be done in different ways depending the references between them. For example: ViewA can call a controller method, ControllerA can handle an event raised by ViewA when ButtonA is clicked, or using EventAggregator (less recommended because it is too decoupled).

3.       ControllerA uses EventAggregator to notify ControllerB that the button has been clicked.

4.       ControllerB shows ViewB in the Region. Since you appear to be using only one view per Region, you are probably using a SingleActiveRegion from a ContentControl. If you are, you do not need to remove ViewA from the region, just add ViewB.

 

The steps can be repeated for ViewB.

 

                Are there any  benefits you want to take advantage of by having another controller?

 

As for the animation it could depend on the specific animation you wanted to perform. A good example of an animation when switching views can be seen in the Stock Trader Reference Implementation. This is executed with a TabControl, but you might be able to get some ideas out of it.

 

Here are some links with more information about the topics I mentioned above:

·         Communication

·         UI Composition

·         How to: Create and Publish Events

·         How to: Subscribe and Unsubscribe to Events

·         How to: Show a View in a Region Using View Injection UI Composition

 

Please let me know if this helps.

 

Damian Schenkelman

http://blogs.southworks.net/dschenkelman

Apr 19, 2009 at 1:54 PM
Hello Damian, thanks for the reply.

My doubt is related with implementing the supervising controller pattern in a complex scenario.
I'm not sure, on the direction to take in implementing a view hierarchy, considering the structure and the interaction between top level and low level controllers/presenters.

Should top level controllers direct reference low level controllers ? Should top level controllers be listening the events propagated by low level controllers. What would be the implementation with the right level of decouple ?
 
The views i described are oversimplified. Both view A and B are composite views, with a typical triad design (M-V-P).
I want to integrate both views in the same region of the shell, where i can swap them using an animation.

View B, for instance, is a composite view made of 4 smaller views, each one having a presenter and model.
The top level animation is triggered by a control that exists in one of these lower level views, like a menu item or a button in a toolbar view.

Your suggestion makes very sense, and the actual implementation is very close to it.
One of the differences is the fact that i use EventAggregator on every events, however you have said "(less recommended because it is too decoupled)". Why is this so ?

Regarding the animation I'm familiar with RI implementation using the tab control, but i was thinking in other type of animation, maybe using SL3.
Anyway, i believe the use of an animation will make me create another composite view that will contain View A and B. Wouldn't it be advisable that in this situation, to create a top level controller that interacts with Controller's A e B?

Regards,
F