In this topic
Extensions vs. application customization
Extensions offer a transparent way of implementing custom behavior across all clients accessing a geodatabase. Whether workspace extensions, class extensions, or both are used depends on the scope required for the custom behavior. An important consideration is that the majority of the customizations possible with these extensions can be implemented at the application level.
The following table compares the relative benefits and drawbacks of developing this behavior at the application and geodatabase levels:
|
|
Application customization
|
Geodatabase customization
|
|
Advantages
|
|
|
|
Disadvantages
|
|
|
These extensions do not extend a class in the object-oriented sense, but can be considered more like "helper" classes. In most cases, attempting to extend a class (in the object-oriented sense) from the geodatabase API is not recommended. Most geodatabase objects implement behavior that is closely linked with other objects in the model; consequently, they are not generally suitable for modification and reuse.
Class extensions
Class extensions are the simplest and most important way to customize geodatabase behavior. They should define custom behavior that applies to a single object class or feature class in a geodatabase, and not to the geodatabase as a whole. In particular, they provide the following capabilities:
- Implementing complex or specialized validation rules using IObjectClassValidation
- Handling edit events, such as object creation, deletion, or modification through IObjectClassEvents
- Listening to relationship class notifications through implementation of IRelatedObjectClassEvents, IRelatedObjectClassEvents2, and IConfirmSendRelatedObjectEvents
- Enhancement of the ArcMap Attributes dialog box with the IObjectInspector interface and Windows forms
- Association of a custom renderer with a feature class extension—IFeatureClassDraw allows a renderer and a property page to be associated with the extension, with the option of being the exclusive renderer for the extension
- Storage of arbitrary objects and data with an object class through extension properties
There is an important distinction between the definition of extension in this case and the definition used in general object-oriented terms. In ArcGIS, a class extension is not a class that inherits its implementation from the ObjectClass or FeatureClass classes. It is a helper class, registered with object classes on an individual basis, and instantiated and disposed of in parallel with the lifespan of the object class in memory. In most cases, it does not extend anything (other than the System.Object class) but implements several interfaces from the geodatabase API.
Custom class descriptions and property pages are often implemented in tandem with class extensions. A class description allows for the creation of object classes and feature classes that are preconfigured to have the extension registered, contain a specific type of custom feature, or have a set of required fields automatically added. Property pages allow the configuration of a class extension through ArcCatalog. Class extensions include properties that are unique to each class with the extension, and property pages provide a convenient method of modifying these. For more information about class extensions, see Creating class extensions.
Workspace extensions
Workspace extensions are also relatively simple to implement. In general, workspace extensions are less important than class extensions and should be used when geodatabase-wide custom behavior is required. This includes the following:
- Filtering datasets that end users should not see or edit—This is a common requirement for data dictionary tables that are specific to an application.
- Implementing methods and properties on a workspace extension—The extension can be a useful place to cache geodatabase wide data or behavior.
- Handling workspace editing events with IWorkspaceEditEvents—These events are also available through editor extensions in ArcMap, but a workspace extension provides a client-independent way of handling them.
- Handling versioning events with IVersionEvents—As with editing events, these can also be handled by editor extensions.
- Handling dataset creation and deletion events with IWorkspaceEvents.
- Handling replication creation and synchronization events by implementing the optional IWorkspaceReplicaEvents and IWorkspaceReplicaSyncEvents interfaces.
As with class extensions, a workspace extension does not extend the Workspace class in the object-oriented sense, but is a supplement to a workspace. There are two types of workspace extensions: geodatabase registered extensions and component category registered extensions.
Workspace extensions registered with the geodatabase behave similar to class extensions in that the extension is required for a client to access the geodatabase. Workspace extensions registered in a component category do not share this property. For more information about workspace extensions, including an expanded discussion about the differences between the two types of registration, see
Creating workspace extensions.
See Also:
Creating class extensionsCreating workspace extensions