This is the first in a 3-part series of articles about caching & Silverlight.Part 1: The client: XAP & Assembly Caching
Part 2: The Silverlight application: Isolated Storage
Part 3: The server: caching your result sets
You can download the source code here.A lot can be written about this subject, and because of that, quite a few misunderstandings about Silverlight and caching exist.Let’s start with a general definition of caching: this is what Wikipedia has to say about this technique: In computer science, a cache is a component that improves performance by transparently storing data such that future requests for that data can be served faster. ... (en.wikipedia.org/wiki/Caching) Well, that sure opens up a lot of possible places to cache, in and outside of your Silverlight application. Can you cache the complete Silverlight application? What’s this assembly caching you keep on reading about? How do you go about keeping your data on the client when navigating to different parts of you application, instead of refetching it all the time? Can you leverage the Isolated Storage for caching, and is it possible to persist data in between different application sessions? Is it possible to share cached items between different Silverlight applications? And what about the server-side: can I minimize database hits when launching queries from my Silverlight application? If you’ve ever asked yourself one (or more) of these questions, this article series is for you. As you might notice when seeing them in the same paragraph, these questions are about different ways of caching, and they all apply to different scenarios. In the first part of this series, I’d like to talk about the caching of your Silverlight application itself and Assembly Caching – almost no code is required for this.XAP Caching
Every Silverlight application consists of one or more XAP files. Smaller applications typically consist of one XAP, but larger applications might benefit from dividing your application into different application modules, compiling into different XAP-files which are loaded on demand. When a user first navigates to a page hosting a Silverlight application, the full XAP has to be downloaded to the client. As an XAP typically contains a bunch of referenced assemblies, your XAML files, compiled code and everything else you’ve included as embedded resources in your Silverlight project, these files have a tendency to get quite big. Therefore, being able to cache these files will reduce the time a user has to wait to access your application.
Read more: Silverlight Show
Part 2: The Silverlight application: Isolated Storage
Part 3: The server: caching your result sets
You can download the source code here.A lot can be written about this subject, and because of that, quite a few misunderstandings about Silverlight and caching exist.Let’s start with a general definition of caching: this is what Wikipedia has to say about this technique: In computer science, a cache is a component that improves performance by transparently storing data such that future requests for that data can be served faster. ... (en.wikipedia.org/wiki/Caching) Well, that sure opens up a lot of possible places to cache, in and outside of your Silverlight application. Can you cache the complete Silverlight application? What’s this assembly caching you keep on reading about? How do you go about keeping your data on the client when navigating to different parts of you application, instead of refetching it all the time? Can you leverage the Isolated Storage for caching, and is it possible to persist data in between different application sessions? Is it possible to share cached items between different Silverlight applications? And what about the server-side: can I minimize database hits when launching queries from my Silverlight application? If you’ve ever asked yourself one (or more) of these questions, this article series is for you. As you might notice when seeing them in the same paragraph, these questions are about different ways of caching, and they all apply to different scenarios. In the first part of this series, I’d like to talk about the caching of your Silverlight application itself and Assembly Caching – almost no code is required for this.XAP Caching
Every Silverlight application consists of one or more XAP files. Smaller applications typically consist of one XAP, but larger applications might benefit from dividing your application into different application modules, compiling into different XAP-files which are loaded on demand. When a user first navigates to a page hosting a Silverlight application, the full XAP has to be downloaded to the client. As an XAP typically contains a bunch of referenced assemblies, your XAML files, compiled code and everything else you’ve included as embedded resources in your Silverlight project, these files have a tendency to get quite big. Therefore, being able to cache these files will reduce the time a user has to wait to access your application.
Read more: Silverlight Show
Posts
0 comments:
Post a Comment