Separate UI from Service stuff

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

Related to
but was unable to reply. Go figure.

In the CompositeUI project, everything UI-independant related to Commands, Configuration, Events, Services, Application Host, State, Module, Threads could be seperatedinto its own project.

Extract Base class could be perfomed on WorkItem; separating state and services from Workspaces and UIElementService.

It would become easy to develop service-oriented components that aren't part of the UI tier (which I must admit, would be more of a Service AB than a UI AB)
Jul 7, 2005 at 5:53 AM
originally posted by: EdJez

With regards to the pckaging of the functionality into the block, we I agree that a finer-grained partitioning would be good - we "bundled" functionality around these domains together more because of the overhead in documenting, shipping and installing each piece together.
I strongly agree with your statement that the "core" services (i.e. event broker, the container model itself etc) would be useful outside of the specific problem area CAB adresses, and we'd love to hear you needs and learnings about applying it in other contexts.
Jul 7, 2005 at 6:19 AM
originally posted by: FrancoisTanguay

I understand.

I've been thinking and working) on a service-oriented framework for a while, that's why I'm so interested in the excellent job you guys have done so far.

Main uses of serviced components I've been working with:
Entities that use: DataAccessService, CachingService, ResourcesService
Application (Independant of any UI): Ressources, Config, Profiles

but even at a finer grained level:
Class that requires an IComparer service
Class that needs to store a parameter received and needs an IStoreService that can be either a WeakStore or StrongStore.....

Same thing for state management:
Instead of passing some widely used parameters around, provide them in a State context.