This project is read-only.


Oct 30, 2011 at 8:59 PM

We are allowed to cache Facebook data for a limited amount of time.  This can be done a few ways.  One is to put all user data in Session, but that's hugely non-performant.  Application state is just bad.  Temporarily storing data in a raw binary or text file, or in a database, requires serialization.  The FGT classes are not serializable.

There are different ways to approach making them serializable but before I go down that path I'd like comments from anyone else who has considered this.  In short, we have a large number of classes, and we get IList<T> collections of related objects.  Some of the classes accept JSON and the class properties are really just a "view" on the JSON.  For this reason it could be ideal to just expose the underlying JSON via a getter.  Does that break encapsulation?  Do we care?  Why would it not be elegant to expose the JSON when elsewhere it could be considered a feature for a class to render itself as JSON?  :)

Making individual objects ISerializable or simply exposing a JSON property is good for instances, but it still doesn't help for collections.  We can serialize myIList.ToList() but then we can't use the IList<T> collections in code like we do now.

Anyway, I'm just thinking aloud.  I don't want to introduce customizations to the SDK that I will constantly need to retrofit, and I don't want to propose changes to the SDK that no one else wants.

So.... ideas?  Thanks!

Nov 5, 2011 at 1:24 PM

You'll be glad to know that one of the changes in the upcoming update is that you can directly access the underlying JSON object.

As for the caching problem, you can tell FGT to cache the GraphApi results by setting the property in web.config.

Nov 11, 2011 at 6:54 PM

So when you publish the new release, what do you think about me making the classes ISerializable?  I'd have to think about how that's done after I see your code.  Custom serialization can be injected via delegates, or we can make classes Partial to allow for more extensibility.  Could you share your thoughts about how you see these as being sealed/internal or more open for developer extensions?  I'm 50/50 on that : core functionality should be immutable but wherever it seems like a developer would want to enhance functionality I think the classes should accommodate.