CSLA with Caching Application Block

CSLA with Caching Application Block

Old forum URL: forums.lhotka.net/forums/t/657.aspx


jgk1701 posted on Tuesday, July 18, 2006

My first post on this forum, although I have been a frequent visitor.  I've been experimenting with CSLA now for about 4 months.  We are getting ready to use it for a major application re-write within the next few months.

I was wondering if anyone here has used the Caching Application Block in conjunction with CSLA?  I'm curious to see what folks have done with it.

Jeff

 

jgk1701 replied on Wednesday, July 19, 2006

bump...surely someone has used the CAB in conjunction with CSLA.

 

Jeff

SonOfPirate replied on Wednesday, July 19, 2006

Jeff,

Take a look at this thread where this discussion has already taken place:

http://forums.lhotka.net/forums/thread/1047.aspx

 

We've implemented the Caching Application Block successfully as described in that thread.  Trick is to find the right place to use it.  In our case we check to see if the requested object exists in the cache before passing the request to the next level of the data portal.  For example, if we are caching locally in the client, the client-side data portal will check to see if the object is in its cache before calling the server-side data portal.  Likewise, the server-side portal will check the cache before resorting to the database.

Keep in mind that all objects in the cache are keyed, so you'll need some way to identify the object that can be used by the data portal.  In our case, we have a standard table schema that uses a uniqueidentifier field for all records that we incorporated into our base data-access class.  The data portal uses this Guid to create its cache key.

There are limits, obviously, to all of this and this key has proven to be the bottleneck.  If you are used to referring to your objects a number of different ways, you can run into problems.  For instance, say you have a User object with a Guid identifier and a unique login/user name.  you should be able to create the object using either value if the username has a uniqueness constraint.  In order to retrieve the same object from the cache with each request, you'll need some sort of key that can be used in both cases.

Not sure if any of that will apply to you, just imparting some of what we experienced.

Hope that helps.

jgk1701 replied on Thursday, July 20, 2006

Thanks for the response.

Ok, this sounds like what I want to do with the CAB.  I want to cache look up tables on both the server side and client sides, in the form of read only collections.

The server side cache would serve as a repository of cached data for clients.  If a BO processing on the server needs access to a look up table, then it can look to the server side cache for that data.  If a requested look up table is not in the cache, then the server side cache would perform the data base access.

The client side cache would cache data for use in combo boxes, list boxes, etc, and also for BO processing.  If a requested look up table is not in that cache, then it would look to the server side cache for that object. 

I'm having a hard time visualizing the architecture we are talking about here.  Any advice?

Also, what to do about situations where the server side data portal is on the client machines?  We wouldn't want a client machine to be maintaining two caches.

Jeff

Copyright (c) Marimer LLC