Getting started with class extensions

In this topic

About class extensions

A geodatabase has out-of-the-box features, such as subtypes, domains, relationship classes, and connectivity rules to define data behavior. However, if you are unable to define data behavior using any of the out-of-the-box features, you can develop class extensions.  
Class extensions are java extension classes that are developed using ArcObjects application programming interfaces (APIs) and deployed to ArcGIS. When deployed to ArcGIS, class extensions can be applied to the appropriate geodatabase object classes (tables) or feature classes in a geodatabase to enforce custom data behavior. 
Typically, a class extension is developed to implement one or more of the following custom data behavior:
The following sections briefly describe the most common use case scenarios for developing class extensions.

Customize attribute validation

Class extensions allow you to implement a complex or specialized attribute validation that cannot be implemented by out-of-the-box subtypes and domains. For example, consider a feature class of water pipes where pipes longer than 10 meters can be made of polyvinyl chloride (PVC) or coated steel, but shorter pipes can be made of many different materials. A class extension can be created to apply this custom validation rule on the material type attribute. See the following illustration: 
In the water pipe example, valid materials are dependent on the pipe length. The usual way to implement dependent validation is with subtypes, since each subtype in the object class can have a separate validation rule (can be configured in ArcCatalog without programming). However, in the example, the dependency is on the pipe length, which is not a suitable attribute on which to base subtypes, since there is no set of discrete values. It is appropriate to create a class extension to define custom attribute validation on a combination of fields (for example, length and material) instead of one field. 
The following are some of the other common custom attribute validations that can be implemented using class extensions:
For more information about customizing attribute validation behavior, see Customize attribute validation

Customize object event behavior

Class extensions can be developed to intercept object events that are fired during the object creation, deletion, or modification and to customize the behavior of these events to implement complex data behavior. For example, a polygon feature class of farm fields is related to a non-spatial object class (named farms). An owner in the polygon feature class might own many farm fields. You want to maintain a total area attribute in the farms object class (table), with the value being a summation of the field areas of each owner in the polygon feature class. See the following illustration:
The preceding example cannot be implemented using out-of-the-box features, such as relationship classes and relationship rules. The solution is to develop a class extension that intercepts the object events of the polygon feature class and customize the event behavior.
For more information about customizing object event behavior, see Customize object event behavior.

Customize relationship behavior

A geodatabase has relationship classes that are similar to relationships you can set up with a database management system. Relationship classes manage the associations between feature classes and object classes (tables), and maintain the referential integrity between the related objects.
A simple relationship class and a composite relationship class are available out-of-the-box. Object or feature classes associated by relationship classes are related object classes. Developing a class extension lets you customize the behavior of the related object events triggered by the related object classes and provides a variation of simple or composite relationships.
The following shows the relationship between utility poles and transformers feature classes: 
In the preceding example, creating an out-of-the-box simple relationship between feature classes cannot maintain the related features spatially. Creating a composite relationship can maintain the spatial relationship, but cannot ignore cascade deletion of the related features. The solution is to implement a class extension to customize the relationship behavior. The specified relationship between the utility poles and transformers feature classes can be achieved by the following:
Implement class extensions to intercept any or all of the relationship events (rotate, move, changed, created), then customize the event behavior as required. If an object or feature class has multiple relationship classes, implement class extensions to filter event notifications of preferred related objects or feature classes. 
For more information about customizing relationship behavior, see Customize relationship behavior.

Class extensions vs. application customization

Class extensions have the simplest and most transparent way of implementing custom behavior across all applications (ArcMap, ArcCatalog, ArcGIS Engine, or ArcGIS Server) that access a geodatabase. Custom behavior provided by class extensions are stored at the geodatabase level. Whether class extensions must be implemented depends on the scope required for the custom behavior. The majority of the available customization with class extensions can be implemented programmatically at the application level using other ArcObjects APIs. 
The following table compares the benefits and drawbacks of developing custom behavior at the application and geodatabase levels (class extensions):
Application level customization
Geodatabase level customization
  • Easier to implement
  • Tightly coupled with the application user interface
  • If customization fails, data remains accessible through other applications
  • Requires deployment to users who require custom behavior
  • Custom behavior is guaranteed for all ArcGIS applications accessing the geodatabase (out-of-the-box and custom)
  • Guarantees a level of encapsulation
  • Business rules specified by the customization can be ignored by running an application without the customization
  • Implementation must be duplicated across several applications
  • Deploy class extensions for all applications, even to view the data
  • If the class extension fails, or is flawed or not deployed, corresponding data cannot be accessed through ArcGIS until the class extension is removed
  • Developers cannot assume that an application is running (can limit functionality)
  • An object or feature class cannot have more than one associated class extension
  • Annotation or dimension feature classes cannot be easily extended

See Also:

How to implement class extensions
Scenario: Customize attribute validation
Scenario: Customize object event behavior
Scenario: Customize relationship behavior