In the previous two posts we have seen how to implement first a Repository that supports change tracking and then a more sophisticated version with self-tracking entities. Having an abstract base class for entities we are able to improve the functionality by adding some means of validation based on Microsoft’s Data Annotations library.
We have learned in the previous post, Part 1 - Fundamentals, a Unit of Work describes a component that supports change tracking. Normally developers have to manage the changes manually. By adding some logic to the entities we enable the container - the Repository - to handle certain changes automatically. We refer to this behavior as self-tracking entities. After having seen how to implement standard change tracking, we are now going to explain the concepts behind self-tracking entities and to evolve our Repository implementation into a completely self-tracked variant.
Many .NET developers enjoy change tracking either since the days with the Data Sets or later with the Entity Framework. This document describes - in four posts - how to easily implement self-tracking entities that fit well into an MVVM application for WPF. As the solution relies on proven concepts, the basic ideas may also be applied to other technologies as well. This post talks about the patterns behind and describes a change tracking implementation.
Whether in front-end or in back-end development, in any project there is the need to generate test data and to fake certain methods (i.e. to isolate from other assemblies) to unit test single components. This article provides a small and simple implementation of a data generator that allows assembling mock objects programmatically. But the article will not dive into faking methods.