I'm currently building an object model library for use in a project. It wraps our internal concepts - Servers, Folders, Items - in an object hierarchy (IFolder, IItem, etc), and we have several implementations of these abstract objects, using a database or an Exchange server as a back-end, so that an IFolder object in our code maps (for instance) to a physical public folder on Exchange. Now I've been wondering how these wrapper/proxy objects should react when their underlying storage is modified. The main usecase is when a folder is deleted, either through my API or directly in the storage layer. Naturally, the object is now orphaned and shouldn't be used, but I still might have instances of it being held in the system. How should it now behave?Right now most of its properties are cached in the object itself to avoid repeated calls to the storage layer. Should these property accessors ping the underlying object to ensure it's still alive?Should I look into a polling mechanism to update the properties, or even see if my physical layer supplied OnChanged events? If my wrapper object finds out that its unerlying storage has been deleted (e.g. because of access to an uncached property returned an error), should it now mark itself as Deleted (so that all access to properties and methods return some sort of ObjectDeletedException) or should it just clear all caches and allow future calls to fail naturally.In short, I'm looking for good tips and best practices for developing an object model wrapper layer. I'll be looking at other similar implementations (Sharepoint Object Model, Managed Exchange Web Services), but any solid guidelines would be appreciated.
How should Object Model wrapper classes behave when underlying objects are deleted?
design patterns;object oriented design