Our WCF web services are not being consumed by any other service, and we highly doubt that they will be. Currently we are only loading about 30 5k objects and have been using web services with success. At this point we are looking at scaling this to support 1,000 objects. Only about 20 will change at any one time. We have a few options and I wanted to see if anyone has had any success with these options:
1) Use SyncFramework. This would be scaleable (we can deploy the local db with our app so startup would not be a major issue), we can use Linq-to-SQL to load the objects, changes are persisted. The main issue is that we would have to redesign or add on to our current, in production, working, approach.
2) Use Web Services with big load up front. Not very scaleable, startup time would be slow (5k * 1000 is ~5 MB, which is a lot even if you're on T1). OTOH, once the initial "startup cost" was spent, the app would be very performant. This would require 0 lines of code change.
3) Use Web Services with load on demand. This would require keeping the loaded objects in memory, checking to see if we've loaded them, and if not, calling the WS to load them. This would require "smart" loading and logic and the app would "slow down" as these objects are loaded. People are getting used to load times between pages as the web becomes more ubiquitious, so that could work in our favor from a usability perspective.
It is also possible that I'm missing something. If you needed to get ~5mb of objects from a server to a client, what would your approach be?
Note: We are using .NET 3.5 with WCF and that cannot change.