Putting it all together—Best practices


Programming with ArcGIS for Server requires programming ArcObjects remotely. You must follow some patterns and rules when programming with ArcObjects for ArcGIS for 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.