I am developing software that uses many calls to a server. On a client side it's a Silverlight application. Almost every time a user clicks on a button in it, it sends 1-5 WCF calls to a server. There can be up to dozen or so users at a time. The server is a database server that serves data to a client. I am an intermediate level developer and am thinking about caching some data and syncing my changes from time to time. Are there any official solutions or technologies for it, like, patterns and such?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
Reduce the number of calls. Caching brings a whole new slew of problems.
One button click resulting in 5 requests suggests maybe the client is too much in control, perhaps implementing business rules and such. Let the server do the processing/thinking. Tell don't ask.
you can use a cross-cutting concern library like, Enterprise library caching block : - http://msdn.microsoft.com/en-us/library/ff647280.aspx, which is highly configurable and useful.
and a better solution, but only if you are using ORM like Nhibernate for example, you have the option first and second level caching: - http://nhibernate.hibernatingrhinos.com/28/first-and-second-level-caching-in-nhibernate
I suggest you study the 'real need' to change your current situation. It is not nice to have all those calls but does it affect your system performance in a noticeable way? If you have the resources to change the current situation, then you may consider one of the options here.
As every one says, reduce the number of calls. You need to examine why you are doing all those calls to the server. Unless the calls to the server are dependent on each other result, then you probably have a generic service interface that needs to be changed. I don't know your database but assuming that it is like Customers, Order Header, Orders, you could return all this data in 1 call. This can be done in different ways, for example you could use LINQ INCLUDE (Eager Loading) or you could write a stored procedure which supports multiple result sets (MARS). The trick here is to balance between the number of calls required and the size of the result returned. You don't want to make a call that returns too much data. Here, the insightful GUI design plays a big role. If your GUI is designed without considering this, you need to tame it. For example, instead of returning 1000 orders in the above scenario, return 10 and allow for paging. Or ask the user if he/she wants to see order details (can have that as a separate button). Of course, this depends on your business needs. If most of the data your are always reading is data that does not change often, say lookup tables, then cashing those makes sense. However, you'll need a mechanism to update this cache. In many businesses, changes to lookups don't happen in an ad-hoc way and can be made at end-of-day or such. However, you need to define and implement how the cache will be refreshed.