ObjectContext - pluggable/overridable for caches, etc?
In the Overview document, Object Services has some listed features including: change tracking and entity loading. My guess is that these are handled by (or via) System.Data.Objects.ObjectContext. Will this class be 'swappable' or otherwise allow extension by allowing pieces of implementation to be plugged in perhaps by implementing certain interfaces?
I am thinking about situations where you might want to handle change tracking differently or load entities from another unsupported source or plugin a high-level cache.
Similarly, extensibility for update processing?
Cheers,
-Matthew Hobbs
While we have had specific consideration for allowing replacement of certain pieces of the system such as the "cache" (more like a state manager than a cache in practice) and other pieces, I don't expect a lot of these to be open for the initial release of the Entity Framework. Extensibility interfaces are permanent (e.g. we maintain them in a supported state for many years) so it's good to see how the system is used first and then in a future release think about how to open the architecture. The testing cost for systems that are very, very open is also very high.
That said, we are discussing some specific extensibility points for the initial release, although I can't guarantee we'll ship them, of course :). One of them is the one you mention: update processing. We still haven't decided all the details, but we're talking about opening a hook for developers to intercept update processing.
If you have specific, concrete scenarios where other extensibility points would be useful, I'd love to hear about them to help make scoping decisions.
Pablo Castro
ADO.NET Technical Lead
Microsoft Corporation
About extensibility of the framework... i have a very common problem in my domain, It is, objects versions. I would like that be easy to implement this feature on top of the framework. It would be nice to mark a EntityType like "versionable" and then framework (with some extension) do all the work.
Thanks.
Carlos F.
 pablo-ms wrote: |
| If you have specific, concrete scenarios where other extensibility points would be useful, I'd love to hear about them to help make scoping decisions. |
|
In my case, I am not interested in replacing any piece of the system, but more on intercepting when certain events occur. Sorry if this is not concrete enough. I am beginning to think about IoC pattern containers that could control things like updates, data validation, lazy/eager loading, etc., as a general solution.
Thanks Pablo, I think one key point of extensibility would be in opening up the way that entities can be added or 'loaded' into the ObjectContext. There are four aspects to this:
a) OnBefore/AfterEntityLoad & OnBefore/AfterCollectionLoad: Expose event(s) on the entity class and ObjectContext for loading the entity (or a collection). The (before) events would optionally allow the default behavior to be bypassed to allow for those all-too-common edge-case scenarios. Also this could be for plugging in an external caching mechanism, logging, etc. Ideally there would be OnBefore and onAfter to allow interception in the OnBefore, and allow further processing (or data massaging) in the OnAfter.
b) Add Entity Method #1 (as if loaded): Expose a method on ObjectContext for adding a pre-created Entity to the ObjectContext. This should at least allow adding a 'fresh' Entity (as if it were just loaded) (i.e. as if called from within an Entity Load Event).
c) Add Entity Method #2 (with change info): The Add Entity Method should be extended to allow for Entities to be added with 'is changed' information. E.g. you may construct an Entity and add it saying to the ObjectContext that this is a changed Entity (e.g. it was submitted from a client, or is being re-attached from another ObjectContext).
d) A follow-on from c) is that here would need to be a method to allow the 'change state' of Entities to be retrievable (and modifiable...) from an ObjectContext for serialization/unserialization into another ObjectContext at a future time. Either for long operations or multi-tier communication.
Most coders will be OK if the Entity Framework does not meet all requirements (the 80%/20% rule) just so long as we have the ability to hook that remaining 20%. If the right entry points are exposed or pluggable, the Entity Framework could be extended in ways we can't think up right now!
Cheers,
-Matthew Hobbs
