For the past 6 months, I have been working on Performance and Memory Analysis for few projects, that became critical when developers chose not to adhere to the best practices.  Teams have started calling me ‘Dr. Perf’ as I board the ship to diagnose the applications – web and windows.  So here I go with one of the most looked after topic ‘Best Practices for Silverlight 2.’  Wherever required, I would direct you to appropriate sites, books and links to have a further read.

 

Design Considerations

 

Silverlight – yes or no?

 

This decision is very vital decision as you are pressing your money, time and your resources behind application development. Choose Silverlight only when

 

1.    Your clients hardware/software supports RIAs

2.    A good network bandwidth to download XAP components

3.    Sections that have more visualizations than that provided by HTML and ASP.NET markups

4.    High-streaming of video/audio is required.

5.    Best for single-screen applications; but can be extended to multi-screens.

 

Where not to choose Silverlight? Say NO when

 

1.    Pages are highly complex

2.    Multi-page user interfaces

3.    Browser specific programming is required (though you actually can do it, you must prefer not to use platform-specific-APIs)

 

Design your application such a way that plug-in installation is non-interruptive

 

Data Accessibility

 

Accessing business logic directly from a Silverlight Application is not advisable.  It is better to encapsulate such logic in Web Services (read: WCF services), just like any other Web Application.  For security reasons, do not put highly sensitive unencrypted business logic on the client. Transferring logic to UI-layer (Silverlight) is preferred only when the performance is a huge hit, but this is done as a trade-off between performance and security.  Put your business validation/rules in a separate assembly so that it can updated independently when rules change.

 

Data store (DB, XML, etc), obviously, will be accessed through these services.  Do not attempt to use local client databases.  Minimize number of round-trips by filtering data at server rather than client end.

 

Accessing local resources of client machine (in client-server arch) will be possible in limits only. So define the scalability of application and request appropriate space from user for your application. Avoid unhandled exceptions by checking if Storage Space is sufficient or not. The .NET cryptography APIs are available in Silverlight and should be utilized when storing and communicating sensitive data to the server if not already encrypted using another mechanism.

 

Application Performance Methods

 

Use appropriate methodologies to boost the application performance.  Ensure that your application has a lightweight foot-print so that users don’t spend too much time in downloading XAP file.  Initially load only code stubs which can lazy-load other modules.  Prefer using inbuilt RIA controls than using 3^rd party controls.

 

Cache your business logic and divide your modules very intelligently. Cache objects that not likely to change during a session.

 

Validate the data before call is given to Web Services. This will reduce the number of trips and make the system more responsive.  If validation logic is too large, consider putting it into a separate assembly.

 

Communication

 

Prefer allocating data pull calls to background worker processes or in separate threads.  If your web service is slow in response, make sure that you keep polling it regularly (say every 5 minutes in a separate thread) to retrieve data.  Long-running processes should be executed in a separate thread to avoid blocking of UI.

 

Ensure that cross-domain configuration is done aptly to have communication with services hosted in other domains.  Consider using Sockets over Web Services when high-amount of information needs to be pushed/pulled to/from server. Example: Rich gaming sites, Stock-trading sites, etc.

 

Exception Handling & Logging

 

Using Exception Handling to control business logic is not advisable.  Catch internal exceptions and decide an appropriate exception propagation strategy – bubbling up to boundary layers.  Provide appropriate notification services for critical errors.

 

Logging component in Silverlight has several limitations. Hence, log errors at client-end and transfer them to server. If using services to implement logging, consider the increased overhead. The added overhead may also change message behavior on the server thus making it harder to use logging to troubleshoot message timing issues.

 

Mobility

 

Check if the plug-in has reduced functionalities for Mobile devices or the same.  If required, incorporate device specific features to improve user experience. Re-examine UI layout using simulators for a smaller screen size. 

 

Deployment

 

Design several modules (XAP-files) instead of a single-large XAP-file, so that individual modules can be downloaded and cached as and when required.  This will also ensure extensibility and modularity in the architecture.  Prefer to have a separate Web Application Server and a Database Server.  A Web Farm can be configured to improve response time.  However, cross domain policies should be implemented and tested. To avoid hardware failures, clustering should be done.

 

Version your components and label them in Source-Safe.

Provide Internet and Intranet links to manually download and install the plug-in if automatic installation cannot be done.

Ensure that your DLLs are obfuscated before deployed to any server.

 

Well, that’s for the first time. I’ll add more to this soon.. Please add in your expertise by commenting to this blog.

Punit Ganshani

Related posts:

• Silverlight 2 Best Practices – II
• Silverlight 2 Best Practices – IV
• Silverlight Training Kit
• Silverlight 2.0 – Advantages, Limitations & Tools
• Silverlight & WPF: MVVM