Consider the example of a polygon feature class of farm fields, which is related via a relationship class to a nonspatial object class of farms. One farm has many farm fields. You would like to maintain a total-area attribute on the farms object class, the value being a summation of the field areas within each farm.
On first inspection it would seem that you should make a class extension on the farms table, implementing IRelatedObjectClassEvents and IRelatedObjectClassEvents2. The RelatedObjectCreated event would add to the appropriate farm's total area and the RelatedObjectChanged event would adjust the total area (if the change was spatial). However this solution is inappropriatethere is no RelatedObjectDeleted event, so the total area cannot be decreased when a polygon is deleted.
The appropriate solution in this case is to extend the polygon feature class (that is, the farm fields) by implementing IObjectClassEvents. The OnDelete event for a farm field would be used to navigate the relationship through to the farms table and decrement the total area. The OnCreate and OnChange events would also make the appropriate changes to the farms table.
In most cases it is simpler and more effective to implement IObjectClassEvents rather than IRelatedObjectClassEvents and IRelatedObjectClassEvents2. These latter interfaces have various disadvantages:
- Performance slows due to an increased number of eventsif the object changed has relationships to many objects, a RelatedObjectChanged event will be fired on each object.
- For example, with a states/counties relationship class, more than 50 counties could receive events for one change to a state. The event triggering can be reduced by implementing IConfirmSendRelatedObjectEvents on your class extension.
- There is no method of catching the deletion of a related feature (though this may be irrelevant if the relationship class is composite).
- The structure of the available events (for example, RelatedObjectSetMoved, RelatedObjectSetRotated) is more complicated to handle than those for IObjectClassEvents.
IObjectClassEvents usually provides a better solution than IRelatedObjectClassEvents and IRelatedObjectClassEvents2.
The main use of IRelatedObjectClassEvents and IRelatedObjectClassEvents2 is when implementing a variation of the composite relationship class behavior, for example, if you want the related object movement and rotation but without the cascading deletion. It would be difficult to implement this behavior with IObjectClassEvents, because there is no simple way of picking up the movement vector or rotation amount of the related feature.
Relationship class notification (also referred to as messaging) triggers the events on IRelatedObjectClassEvents and IRelatedObjectClassEvents2. Setting the notification on a relationship class to anything other than 'None' is only appropriate in two situations: when you implement IRelatedObjectClassEvents or IRelatedObjectClassEvents2 or for composite relationship classes.