Best practices

About best practices

• Connecting to a GIS server:
• Use the native connection object of the environment in which you are developing your application (.NET or Component Object Model [COM]).
• If you are writing Web applications or Web services, use impersonation to fix the identity of your application to a user in the geographic information system (GIS) servers users group (agsusers).
• Programming 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 a 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 the application state that you can maintain in a .NET session state 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.
• Working with 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 the CreateObject method (the exception is 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.
• Working with Web controls:
• Web controls manage the MapDescription in your application's session state.
• Web controls create and release server contexts.
• For pooled objects, the Web controls create and release the server context on each request. For non-pooled objects, the Web controls 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 multiple fine-grained ArcObjects calls are necessary, consider extending the server by creating COM 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 numerous 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.