LinqConnect tracks changes differently for different kinds of entities. Let's discuss the following entity kinds:
LinqConnect entities.
These are entity classes, generated by the 'LinqConnect' template, which is used by default (so if you have not changed template, you probably use this kind of entities). These entity classes implement INotifyPropertyChanging and use EntitySet for navigation properties of the many side. LinqConnect processes such entities in an optimal way and provides the most of the features for change tracking. The drawback of using this kind of entities is that there are certain requirements on implementation of entity classes, and they depend on the Devart.Data.Linq.dll assembly, which contains the EntitySet class. It can be not so convenient to redesign existing business logic for LinqConnect entities. However if you start application development from scratch, use of this kind of entities can ease development and increase application performance.
LinqConnect POCO entities.
These entities are implemented in the same way as LinqConnect entities except for their navigation properties. These are usual objects and lists, so the entities does not depend on the Devart.Data.Linq.dll assembly.
These entities are generated by the 'POCO Entities' template. They are good for the layered architecture - entity classes can be implemented on the business logics layer, and it's not a very good idea to make business layer dependent on the LinqConnect runtime.
Changes in collection navigation properties are checked by copying and enumerating the collections. So, it is strongly recommended to create a new context for each unitof work to avoid the accumulation of a large number of entities that are not used any more in the cache because all cached entities need to be checked for changes when submitting modifications.
True POCO entities.
These entities can originate from different sources - legacy code, custom template, etc. They don't implement INotifyPropertyChanging and don't use EntitySet. Change tracking is most expensive in case of such entities because LinqConnect must store a copy and check collections for changes by enumerating them for all entities. In such case it's especially recommended not to keep the context alive for a long time.