2

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.

  • 1
    Don't go for polling. Go for notifications. When something obtains a reference to a folder, make it an observer of that folder, when anything happens to the folder it can then notify its observers without knowing anymore about them. The notification method called by the observed on the observer can pass any info you need. This is known as the Look into the observer observed pattern, which is also known as the publisher subscriber pattern. Also have a look into using interfaces. They make decoupling your code much easier. – Marjan Venema Sep 29 '13 at 16:55
  • As you can see in my first paragraph, I am using interfaces - I have an IFolder interface, and different implementations (ExchangeFolder, DBFolder, etc) implementing it. I'm less concerned about the outward facing interface, though, than I am about the inward storage-facing behavior. – Avner Shahar-Kashtan Sep 30 '13 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.