Putting it all together—Best practices


Programming with ArcGIS Server requires programming ArcObjects remotely. You must follow some patterns and rules when programming with ArcObjects for ArcGIS Server The following is a summary of the programming rules and best practices for developing applications.
  • Connecting to the server
    • Use the native connection object of the environment in which you are developing your application.
    • If you are writing Web applications or Web services, you need to use impersonation to fix the identity of your application to a user in the geographic information system (GIS) servers users group (agsusers).
  • Working with server objects
    • You get a server object's context from the server, and the server object from its context.
    • A server object exposes a number of coarse-grained methods. You can also access the fine-grained ArcObjects associated with a server object.
    • A server object can include one or more extensions that extend the base functionality of the server object.
    • When your request on a server object is finished, you must release the server object back to the server by releasing its context.
  • Managing application state
    • Pooled server objects are intended for stateless use.
    • Non-pooled server objects support stateful use.
    • There are aspects of your application state you can maintain without making stateful use of the GIS server.
    • The keys to scalability are to make stateless use of the GIS server, use pooled server objects, minimize the time your application holds on to a server object, and explicitly release it.
  • Server contexts
    • All ArcObjects in a server application run in server contexts.
    • You are responsible for releasing a server context when you are finished working with its objects.
    • Always create ArcObjects in a server context using its CreateObject method (the exception being the server connection object).
    • Objects work best together if they are in the same context.
    • Do not directly use objects in a server context with local objects and vice versa.
  • Web controls
    • Web controls handle managing the MapDescription in your application's session state.
    • The Web controls create and release server contexts for you.
    • For pooled objects, the Web controls will create and release the server context on each request. For non-pooled objects, the Web controls will hold on to the same context for the duration of the session.
  • Performance tuning
    • Minimize the number of fine-grained calls to remote ArcObjects.
    • If a large number of fine-grained ArcObjects calls are necessary, consider extending the server by creating objects that move the fine-grained ArcObjects usage into the server, or by creating server object extensions.
    • Do not allow application users to perform queries that result in a large number of rows, and limit the number of results from queries that you process.
    • Work with your GIS server administrator to ensure that the built-in limits for queries and output for a particular MapServer or GeocodeServer are configured appropriately for your application.