State, events, MVC in service or database apps.

Topics: CAB & Smart Client Software Factory
Jul 18, 2005 at 5:10 PM
originally posted by: ptorrsmith

We are using the CAB to build an application with a SOA style architecture. Our app has one module, which kicks off a WorkWithCustomersWorkItem. This workitem calls to the service for a summary list of customers (response object). When the user clicks on a customer in that list, the workitem spawns a customer-specific workitem (as per BankTeller ex), passing a customerid (or customerSummary object) through to the child workitem's Run() method, which then needs to call the service to get full details (and later to update a customer).

In the above scenario, the WorkWithCustomersWorkItem has in its State dictionary a "CustomersSummary" list (List<CustomerSummary>) with basic details. Each of the customer-specific child workitems (WorkWithCustomerWorkItem) will have their own State dictionary with a "CustomerFull" object (got from dbservice).

Could someone please describe (from an MVC and CAB perspective) the ideal flow of method calls, data, and events (StateChanged and CAB events) that schould occurr to (a) update the database via the service, and have that change reflected in the customer details view and the customer summary list view.

As I understand it (open to a better way):

1. When I update a customer's details (through a SmartPart "CustDetails" within a WorkWithCustomerWorkItem), MVC convention would have it that the view does not act directly on the model, and as such, the view should not change the state (ie its "CustomerFull" object), but instead should pass the smartpart's customer details to the workitem (via controller) to make the UpdateCustomerDetails(CustomerFullDetailsUpdateRequest).

2. If that is successful (service response.errors.count==0), then the workitem can then either (a) make a service call to get the refreshed CustomerFull object details (seems a bit redundant?), or (b) use the local data it used to make the initial update request, to update the WorkWithCustomerWorkItem's CustomerFull object in local State.

3. We should then raise a "global" CAB event (eg "topic://WorkWithCustomer/CustomerDetailsUpdated", EventScope.Global), and pass in the DataEventArgs a reference to the specific CustomerFull object (or just the Customer id??).

4a. The "CustDetails" smartpart will have subscribed to this event topic, and will respond by rebinding it's controls to the CustomerFull object in its workitem's State collection.

4b. The parent WorkWithCustomersWorkItem will also have subscribed to this event topic, and will respond by either making a service call for the CustomerSummary details for that customer or just using the reference to the CustomerFull object to update the specific CustomerSummary object properties in its List<CustomerSummary> in its local State.

As we have several workitems and sub (sub) workitems each concerned with different scopes of data, it's a bit unclear to me as to what is a good MVC style pattern to adopt for updating and eventing, and State management.

On top of all this I will have to implement polling of the dbservice to see if data has been changed externally and will then need to have workitems do their updating of state and raising events. It all seems a bit messy, even for a simple prototype application like ours, so we could do with some good guidance in this area of database/ service driven/dependant CAB applications.