Silverlight Best Practices (Part 1 of 4)
I have been working on Designing and Development of Rich UI applications on Silverlight, and Windows Phone platforms and high performing applications as middleware components for Trading Applications. One of the biggest issues I have seen is non-adherence to standards causing slowness in applications, or a red-mark in Audits due to mis-fit of technology stack. To help developers decide whether to opt for Silverlight and when designing what should be taken care of, this series of articles are written. Wherever required, I would direct you to appropriate sites, books and links to have a further read to avoid duplicacy of text on two websites.
This article has been edited and republished on demand.
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
- Your clients hardware/software supports RIAs
- A good network bandwidth to download XAP components
- Sections that have more visualizations than that provided by HTML and ASP.NET markups
- High-streaming of video/audio is required.
- Best for single-screen applications; but can be extended to multi-screens.
Where not to choose Silverlight? Say NO when
- Pages are highly complex
- Multi-page user interfaces
- 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 or trusted 3rd party controls offered by Telerik, Infragistics, Visifire, etc.
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.
Check out alternatives such as Nirvana for light weight push mechanism
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.
