In this topic
The functionality of ArcObjects can be accessed using four application programming interfaces (APIs): Component Object Model (COM), .NET, Java, and C++. The decision of which API to use depends on a number of factors, such as the ArcGIS product with which you are developing, the end user functionality that you are developing, and your development experience with particular languages. When working with ArcObjects, developers can consume functionality exposed by ArcObjects or extend the functionality of ArcObjects with their own components. When referring to these APIs, there are differences with respect to consuming and extending the ArcObjects architecture.
The APIs support consuming the functionality of the ArcObjects components; however, not all interfaces implemented by ArcObjects are supported on all platforms. In some cases, interfaces make use of data types that are not compatible with an API. In situations like this, an alternative implementation of the interface is provided for developers to use. The naming convention of a GEN postfix on the interface name is used to signify this kind of interface; IFoo would have an IFooGEN interface. This alternative interface is usable by all APIs; however, if the non-generic interface is supported by the API, it is possible to continue to use the API-specific interface.
Since ArcObjects is developed in C++, there are some cases
in which data types compatible with C++ have been used for
performance reasons. These performance considerations mostly
affect the internals of ArcObjects; hence, using one of the
generic interfaces should not adversely affect performance
of your ArcObjects developments.
Extending ArcObjects requires creating your own objects and adding them to the ArcObjects architecture. ArcObjects is written to be extensible in almost all areas. Support for extending the architecture varies among the APIs and, in some cases, varies among languages of an API.
The majority of differences between the API support for
ArcObjects revolves around data types. All APIs fully
support the following automation-compliant data types.
Differences occur with data types that are not Object
Linking and Embedding (OLE) automation compliant.
The COM API provides the most possibilities for extending the system. The limitation within this API is with the VB language. Visual Basic does not support the implementation of interfaces that have one or more of the following characteristics:
- The interface inherits from an interface other than IUnknown or IDispatch. For example, ICurve, which inherits from IGeometry, cannot be implemented in VB for this reason.
- Method names on an interface start with an underscore ("_"). You do not find functions beginning with "_" in ArcObjects.
- A parameter of a method uses a data type not supported by VB. IActiveView cannot be implemented in VB for this reason.
In addition to the limitations on the interfaces supported by VB, the binary reuse technique of COM aggregation is not supported by VB. This means that certain parts of the architecture cannot be extended; Custom Features is one such example. In reality, the previously discussed limitations of VB have little effect on the vast majority of developers, since the percentage of ArcObjects affected is small, and for this small percentage, it is unlikely that developers will have a need to extend the architecture. Other COM languages, such as Visual C++, do not have these limitations.
The .NET API supports extending ArcObjects fully, with the one exception being interfaces that make use of non-OLE automation-compliant data types. See the following illustration for a complete list of all OLE automation-compliant data types.
The COM and .NET APIs are only supported on the Microsoft Windows platform.
The ArcObjects Java API supports extending ArcObjects in the core areas of Visualization, Geoprocessing and Geodatabase management. To learn more about extending ArcGIS functionalities using Java API, refer topic Introduction to Extending ArcGIS .
The ArcGIS applications are rich, professional geographic information system (GIS) applications with much functionality, but if viewed simply, the applications can be broken down into a series of toolbars along with a table of contents (TOC) and map viewing area. The desktop applications are all extended by adding new commands and tools. In a similar way, developers can build applications with rich functionality using any of the four ArcGIS APIs.