Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Wow. Your question is quite open-ended. Why are you making 1-5 WCF calls per click? –  Jim G. Apr 12 '12 at 8:20
1  
As a rule of thumb, its better to have single fat messages over frequent thin messages. It might be would be worth seeing if you can combine some of your messages. –  Martin Clarke Apr 12 '12 at 8:37
4  
@MartinClarke: depends a bit on whether you are communicating over a WAN or a LAN. Over a WAN, yes, a lesser number of fatter messages is worth the effort. Over a LAN latency is less of a concern and a greater number of smaller more focussed messages (high cohesion, low coupling) can be more desirable. –  Marjan Venema Apr 12 '12 at 9:16

3 Answers 3

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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.