views:

66

answers:

2

I'm developing a web app for which the client wants us to query their data as little as possible. The data will be coming from a Microsoft CRM instance.

So we've agreed that data will only be queried as and when it is needed, therefore if a web user wants to see a list of contacts (for example) that list is fetched into a local DataTable. Then if a new contact is created on the website the new contact is sent to CRM and added to the local DataTable at the same time. Likewise for edits.

If the user then looks at their contacts again the data will just come from the local DataTable.

At the moment local data is being kept in Session but my concern is that too much memory will start being used up. However traffic is expected to be pretty small, perhaps no more than 20 concurrent users so am I worrying about nothing or is there a better way you can suggest to handle this?

+1  A: 

You worry about nothing. Basically it is a scalability dump - stupid desig. BUT: if you can throw 1gb of memory at the problem, for 20 users, storing 16mb of memory is not a problem.

The main problem starts when pepople count grows and the application needs to be rewritten.

TomTom
+1  A: 
  • 20 concurrent users is not too many.

  • Clients "looks at their contacts": Depending on "contacts" table size, could you consider storing it in in-memory dataset( all contacts). You could then filter acc to primary key.
    Alternative to session:Cache, Application

Cache with SqlCacheDependency and CacheItemRemovedCallback should be a good option to session.

  • XML files for each customer contacts.
PRR
Thanks, I hadn't really considered your 2nd point. I'll look into expected data volumes in the live environment.
Fishcake