Architectural Challengs

Our team recently started researching the possiblity of using .NET Smart Clients. Smart Clients are appealing to us because using Windows Forms provides (well, we will see) for a faster, cleaner and more robust [rich] presentation layer. Sure, web based apps bring a lot to the development table too, but I have found it difficult to provide the functionality our users want or need, and when we do find a way to do it, the application ends up as a series of hacks or kluges leaving the code fragile and brittle.

.NET Smart Clients are new to our team, and as such there is a significant learning curve for our team. Most of the challenges seem to be high-level and architectural. While doing some research, I found a good article that highlights some of the challenges. Here is a snippet that confirmed some our proto-typing decisions:

-- snippet from MSDN article --

Smart Client Architectural Challenges
The architectural challenges of smart clients differ from those of thin clients, and you will need to account for them in your application design. The benefits of smart client applications are significant, but you can realize them only if you address these challenges appropriately.

Smart clients allow data and logic to be distributed to the client computer, whereas thin clients tend to keep the data and logic centralized on the Web server and other back-end services. Although the smart client approach allows you to make the application more efficient, with no round trips to the server to determine next steps, you need to consider that the application and its data are now more widely distributed than with thin client applications, and modify your design accordingly.

If you are implementing business rules on the client, you will need to update those rules as required, without updating the entire application. This may mean that you use differing mechanisms for updating the application and updating business rules within the application.

By caching data on the client, you can significantly improve the performance and usability of an application, but you must ensure that the data is refreshed appropriately and that stale data is not used. Because many users can access and use the same data, you must also consider the effects of data concurrency. Your application must be able to handle data conflicts or reconciliation issues that arise because the application is now more widely distributed and can operate while offline. Chapter 3: Getting Connected covers these issues in depth.

The .NET Framework provides a great deal of flexibility in how your smart client applications can be hosted. Applications can be run as traditional desktop applications or can be hosted within Office or Microsoft Internet Explorer. Many combinations are possible. For instance, a Windows Forms application can host Internet Explorer or Office components, and any host can subsume any other.

You can factor volatile application logic (for example, business rules governing volume order discounts) into assemblies that are downloaded on demand over HTTP. Doing so obviates the need to deploy new versions of the client application as new application logic is developed. You can use the same model for additional (or infrequently used) application features, so that initial application size is kept to a minimum, and additional features are installed on an as-needed basis.

You may choose to deploy your smart clients as composite applications, where many applications combine to form a coherent solution. Such solutions can be formed by coupling desktop applications, or by providing a generic shell application that houses multiple lightweight applications that together form the solution.

Composite applications are particularly useful in situations where users have to access many applications to do their work. For example, customer service agents in call centers typically have to work with many LOB applications, including desktop, browser-based, and terminal-based applications. All such LOB applications can be hosted within a generic Windows Forms application that provides integration between them, greatly simplifying the user's job and, most importantly, reducing the time spent on a particular call. By providing a generic shell to host these LOB applications, common infrastructure features, such as security, deployment, window management, application integration, auditing, and so on, can be developed, tested, and reused across different solutions, freeing the developers of the LOB applications to focus on business functionality.

The advent of service-oriented architectures means that you can design smart clients to make use of network services. All such services are provided in an industry-standard way, which improves interoperability, developer tool support, and the ease with which new features can be built into the smart client application.



-- end snippet from MSDN article --

For our initial prototype, we opted for the Shell/Plug-in archtitecture. I think this is good because it provides for a common architecture or framework for the desktop apps, security is unified and updates to code should be seamless or transparent for the user. Lets see...

For the complete article visit here...