From 9eeeace34bfbbb8544ba12aa101b1fc7d620676f Mon Sep 17 00:00:00 2001 From: Shimmy Date: Wed, 10 May 2017 20:07:53 +0300 Subject: [PATCH 1/2] Layout --- README.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 5ce7aa0..caecd6d 100644 --- a/README.md +++ b/README.md @@ -9,9 +9,7 @@ TrackerDog works on seamlessly turning your .NET objects into change-tracked obj 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? @@ -34,4 +32,4 @@ So, what happens when you don't use an _OR/M_ or, even worse: **what happens whe 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. \ No newline at end of file +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. From db2a077d78d54df0791a6e3036d95b306f7e7715 Mon Sep 17 00:00:00 2001 From: Shimmy Date: Wed, 10 May 2017 20:11:10 +0300 Subject: [PATCH 2/2] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index caecd6d..edaf304 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ Most enterprise applications work with _object-relational mappers (OR/M)_ like _ 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?** +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 a _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!