Wednesday, May 1, 2013

fat client versus thin client

User Interface applications are referred to as clients. Depending on how much business logic is in the client, it can be considered fat or thin. When we add non-functional requirements to the front end such as security, there are many ways in which the application can quickly bloat. One of the ways to reduce the redundancy and streamline the application is to keep fewer controls. When that is not an option, separating out clients for roles could also be considered. Controls require flags for their behavior and these flags and corresponding methods may need plumbing in every layer. Typically this is what adds to code bloat.
In this context, it is probably relevant to mention what a smart client is. A smart client is a composite UI application block. This is a microsoft patterns and practices software which can be used for the following:
Online transaction processing such as for data entry or data distribution centers
rich client portals such as for bank teller applications or one that requires several backend services
UI intensive information-worker standalone applications
All the scenarios mentioned above require rich client interaction, a shell architecture that can host the user interface, the business logic and the centralized control
The composite UI application block  makes it easy for you to develop your client applications  in three ways:
1) it allows the application to be based on the concept of modules or plug-ins
2) it allows separation of UI from shell client such that the business logic can be developed without encumbering client complexity.
3) it makes it easy to develop with patterns so that modules are loosely coupled.
Let us take an example of a User interface application for a call center application. This UI will likely have multiple collaborating parts for addressing business processes such as billing, claims or customer information. All of these parts could potentially be developed by different teams or interact with different backend systems and each can be independently developed, versioned and deployed. Yet the application provides a seamless and consistent experience to the users.
Let's take a look at the architecture for this application block. The design of this application block focuses on the following
1) finding and loading modules at application initialization to dynamically build a solution.
2) separating development of user interface and shell from that for business logic
3) achieving reuse and modularity of the code
Consequently the subsystems include the following:
modules for application initialization such as Authentication, Enumerator, Module Loader, and CabApplication
States and events such as event broker, state persistence and commands,
Shell interface such as IWorkspace, IUIElementAdapter, IUIElementAdapterFactoryCatalog and ISmartPartInfo.
The finding and loading of modules is based on a catalog that registers which modules to load and a module loader that actually loads and initializes the components that comprise of your application.  The modules could vary from application to application but the architecture remains the same.
WorkItems describe which collaborating components participate in a use case, share state events and common services. An event broker enables objects to register their event handlers with. State is where multiple components can place or retrieve information.
This article courtesy of the literature on msdn.

No comments:

Post a Comment