Generic object change tracker for .NET Framework and .NET Standard-compliant platforms like .NET Core and Xamarin!
C# PowerShell
Clone or download
Latest commit 147f760 Dec 31, 2017

README.md

Welcome to TrackerDog!

trackerdog build badge project logo

What is TrackerDog?

TrackerDog works on seamlessly turning your .NET objects into change-tracked objects. It can track a full object graph, including collection properties.

Also, since version 2.2.0, TrackerDog works on both full .NET Framework and .NET Standard-compliant platforms like .NET Core or Xamarin!

How to install it?

TrackerDog is distributed as a NuGet package called TrackerDog. Follow this link to get installation instructions.

Getting started

Follow up this tutorial to become object change tracking expert!

If you're looking for API reference, follow this link.

Why TrackerDog?

When implementing some design patterns like Unit of Work in a very seamless way, it is required that the whole Unit of Work could track object changes and produce new or updated object persistence actions in order to let a given peristence layer work on the so-called operations.

Most enterprise applications work with object-relational mappers (OR/M) like Entity Framework and NHibernate which, as full OR/M frameworks, they can track persistent object changes and generate an underlying SQL INSERT, UPDATE or DELETE under the hoods thanks to their built-in change tracking.

At the end of the day, these OR/M frameworks implement change tracking turning your POCO class instances into proxies that intercept your POCO property changes and once you call the commit-specific method of their built-in unit of work they can persist changes to the database without your intervention.

So, what happens when you don't use an OR/M or, even worse: what happens when you don't use an OR/M but you want to implement an unit of work capable of tracking your POCO changes?

A good example of implementing a change tracking can be an unit of work to provide an abstraction layer over a NoSQL driver like Mongo, Couch, Cassandra, Redis... Even when some of them have some kind of atomically-executed set of commands, they will not track changes in your application layer. Actually there should be more possible use cases, but one of most important use cases is implementing a true domain-driven design architecture ensuring that a domain unit of work can track changes either when you use a regular data mapper (for which you won't use TrackerDog) or you want to implement repositories that return change-trackable domain objects!

In summary, TrackerDog turns your object graphs into interceptable object proxies that share a common change tracker which let you check what has changed in your objects or even accept or undo changes to a given object graph.