Coffeehouse Thread

5 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

read-thru/write-thru cached generic list?

Back to Forum: Coffeehouse
  • User profile image
    itsnotabug

    i've been thinking about an abstract data structure that seamlessly caches a list of Something and exposes overrides like OnSomethingAdded, OnSomethingDeleted, OnSomethingUpdated for you to handle the persistence to a backing datastore. GetSomethingById(), GetAllSomethings(), AddOrUpdateSomething(), etc... methods on the list would do the standard caching patterns like checking whether the Something was in the list by key and acting on it, if not, then it would try to find it in the database by key, if it's found then it would add it to the list and return the Something or null. has someone already built something like this? time to expire and linq support against the list would be nice too. i'm sure the full-fledged orms have already figured this out, but i'm looking for something light-weight.

  • User profile image
    Dr Herbie

    Sounds like a Repository without the Unit of Work part ... a 'live repository'?

  • User profile image
    itsnotabug

    yeah i suppose so, but i'm thinking that it shouldn't be aware of the implementation of the backing store and generalized for any List<T>. most repository patterns i've seen have a distinct repository per entity/table. i could use a micro-orm like sqllite, dapper or petapoco to get the typed entity experience and convenient crud stuff within my concrete implementation. the more i think about it, it becomes trickier, especially if i'm working with a large table that wouldn't necessarily fit in memory, so there would have to be rules about invalidating/removing from cache the rarely used items.

  • User profile image
    ScanIAm

    , itsnotabug wrote

    yeah i suppose so, but i'm thinking that it shouldn't be aware of the implementation of the backing store and generalized for any List<T>. most repository patterns i've seen have a distinct repository per entity/table. i could use a micro-orm like sqllite, dapper or petapoco to get the typed entity experience and convenient crud stuff within my concrete implementation. the more i think about it, it becomes trickier, especially if i'm working with a large table that wouldn't necessarily fit in memory, so there would have to be rules about invalidating/removing from cache the rarely used items.

    I wrote something similar to this for a project in the past to manage specific objects (not generic).  As I recall, it was pretty simple, however, to implement.  the only hard part came from making it multi-threaded so that it could be populated and have the cache managed by separate threads.  I don't have the source, though, so I'm effectively just bragging :(

     

  • User profile image
    itsnotabug

    yes this gets even trickier with multi-threading. maybe the newer ConcurrentDictionary would be better used for this. i'm essentially going for a 'live' cached generic List<T> that automatically syncs to it's corresponding db table on touches. i can eliminate a lot of the complexity if i just assume that the entire table will fit in memory.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.