Bank Teller Sample Reuse

Topics: CAB & Smart Client Software Factory
Jul 6, 2005 at 4:07 AM
originally posted by: FrancoisTanguay

Let's say I'd like to reuse the CustomerQueue (Controller, View, Service)

So MyWorkItem will create my own main View (MyMainView) to contain the CustomerQueueView which uses CustomerQueueController.

However, CustomerQueueController downcasts WorkItem to BankTellerWorkItem to call WorkWithCustomer.

I'm wondering how it should have been designed in order to allow reuse.

Should we have CustomerQueueWorkItem that encapsulates its View and Controller?

But then, should it be the responsibility of CustomerQueueWorkItem to implement WorkWithItem(...) and run CustomerWorkItem?

Or should it do nothing and let the parent WorkItem(BankTellerWorkItem or MyWorkItem) handle the QueueCustomerSelectionChaged event?


IMHO, CustomerQueue MVC contract should be to display results of a queue service and raise QueueCustomerSelectionChaged event. Its public contract is then to act as an Employee Selection component.
Jul 6, 2005 at 5:01 AM
originally posted by: BradWilsonMSFT

We believe that the reuse points are probably easiest expressed as work items. If the granularity of the work item is too large for it to be reused, I'd suggest that the first step would be to refactor out the appropriate work items to aid reusability, and then reuse the work item. This would be the way we'd recommend doing it.

That said, if you'd rather reuse view/controller pairs, then you can refactor an interface out of the work item, and express the needs of the controller and view in terms of the interface instead. Then an appropriate work item would implement the interface, and your view/controller pair could be sited in any work item that implements the interface.
Jul 6, 2005 at 5:57 AM
originally posted by: FrancoisTanguay

So let's say I want to refactor CustomerQueueController in a way that it does not depend on BankTellerWorkItem.

1st scenario:
- Make CustomerQueueController depend on interface ICustomerWorker { void WorkWithCustomer(Customer c); }
- Implement ICustomerWorker in BankTellerWorkItem

Pros: ?
Cons: CustomerQueueController's Work Item must implement the interface. There is no easy way to handle the customer selection elsewhere.

2nd scenario
- Let CustomerQueueController raise a CustomerSelected event.
- Let anyone, anywhere handle this event.

Pros: Flexible
Cons: All needs of CustomerQueueController might not be easily answered by event publication.



For having dealt with that kind of scenarios in a MVC framework in a huge app, I personnally prefer the latter.
CustomerQueueController gets an easy contract. Publish List selection changes.

I'd even go further by defining a CustomerSelectionWorkItem that is solely responsible for creating the view and showing it in the workspace.
Jul 6, 2005 at 6:10 AM
originally posted by: BradWilsonMSFT

Yes, I think our preferred recommendation would be your very last suggestion: refactor out CustomerSelectionWorkItem, from which you would publish an event (either a simple .NET event, or using our EventBroker, depending on your needs).