The DataContext provides the primary interface for fetching data and managing from an adTempus server.

While the Scheduler represents a connection to an adTempus server, Scheduler the DataContext allows a client to work with separate, isolated copies of objects from that server.

Each DataContext maintains a cache of all the objects that have been fetched through it, and guarantees that any operations you perform on an object with a given identity will operate on the same copy of the object.

For example, suppose you fetch a CredentialProfile for user "bob" through the DataContext. Subsequently you fetch a job that uses CredentialProfile "bob." When you ask the job for its CredentialProfile, the object you get back will be the same copy of the object that you previously fetched from the DataContext.

Conversely, DataContexts and the objects that belong to them are isolated from each other. If you fetch the CredentialProfile for "bob" through a second DataContext, you will get a separate copy of that CredentialProfile. If you make changes to that CredentialProfile, those changes will not be reflected in the copies that belong to other DataContexts.

To enforce this isolation, objects are not permitted to be used across DataContext boundaries. For example, if you fetch a CredentialProfile in DataContext A, you cannot assign that CredentialProfile to a Job that you fetched through DataContext B. If you try to do this, the assignment operation will throw a BoundaryViolationException.

The one exception to this rule is the Scheduler.ReadOnlyDataContext exposed by the Scheduler. This special context is intended to be used for fetching lists of reference data for use when editing other objects. Objects fetched through this DataContext can be used in other DataContexts. However, objects fetched through the ReadOnlyDataContext cannot be modified.

Generally a DataContext should be short-lived, discarded after updates made within the context have been saved. For example, in the adTempus Console, the list of job groups, jobs, etc., is fetched through a DataContext that is kept alive for the entire time the Console is running, but the data fetched through that DataContext is not updated in the Console. Instead, when a user wants to edit a Job or other object, the Console creates a new DataContext and fetches a copy of the desired job into that new DataContext. All edit operations now operate on objects in this separate context, keeping them isolated from the rest of the Console, and vice-versa. For example,

• The job list in the Console is refreshed from the server periodically. Since this operation uses a different context, the copy of the Job that is being edited is not overwritten by the refresh operation.
• Similarly, in-progress changes to the Job being edited are not reflected elsewhere in the Console until the job has been saved.

Once the user has finished editing the job (saving or discarding the changes), the DataContext is disposed.

To create a new DataContext, use Scheduler.NewDataContext.

System.Object
   ArcanaDevelopment.adTempus.Client.DataContext

Reference

DataContext Members
ArcanaDevelopment.adTempus.Client Namespace