Unit of Work Optimization

For best performance when using a unit of work, consider the following tips:

• Register objects with a unit of work only if objects are eligible for change. If you register objects that will not change, the unit of work needlessly clones and processes those objects.

• Avoid the cost of existence checking when you are registering a new or existing object (see "Using Registration and Existence Checking").

• Avoid the cost of change set calculation on a class you know will not change by telling the unit of work that the class is read-only (see "Declaring Read-Only Classes").

• Avoid the cost of change set calculation on an object read by a ReadAllQuery in a unit of work that you do not intend to change by unregistering the object (see "Unregistering Working Clones").

• Before using conforming queries, be sure that it is necessary. For alternatives, see "Using Conforming Queries and Descriptors".

If your performance measurements show that you have a performance problem during unit of work commit, consider using object level or attribute level change tracking, depending on the type of objects involved and how they typically change. For more information, see "Unit of Work and Change Policy".