Layout

[weitzhandler]

No description provided.

[mfidemraizer]

Hey, thank you for the fixes.

Is it possible that you use git rebase -i head~2 and you turn these 2 commits into 1, please? This way your PR will be represented by a single commit.

Thank you again for the effort :)

[weitzhandler]

Hi, and nice to personally thank you for this great lib.

I spend the last few hours exploring the idea of change tracking, and I like the idea very much, but I prefer using this because it leverages the use of built-in interfaces such as INotifyPropertyChanged, IRevertibleChangeTracking, IChangeTracking and reuses some ideas already in the system.
Am I getting anything wrong?

And BTW, the Project Site link in the nuget page is broken.

[mfidemraizer]

In fact, I developed TrackerDog after trying to fix some issues on the lib that you linked in your comment!

IMO, I found that it had some design flaws and it wasn't maintained very much, and I mandatorily required change tracking to advance in some project, thus, I thought that creating my own library would be better in the medium term since there were no good alternatives to Joel's one.

In the other hand, TrackerDog auto-implements INotifyPropertyChanged and INotifyCollectionChanged. If you really need IRevertibleChangeTracking and IChangeTracking too, it shouldn't be a great effort for me to auto-implement them too, why not!

Maybe I'm biased because I'm the author of TrackerDog, but TrackerDog is more future proof, because it's a .NET Standard library which already works on .NET Core and Xamarin on Android, and obviously on the .NET Full Framework. Also, it has extensibility points to customize it (and I can add more points to extend it if you need them).

Why don't you open a new issue to track your request of supporting IRevertibleChangeTracking and IChangeTracking? Probably I'll be able to implement that change in few days!

Thank you again and I'll look forward for your comments/issues.

[weitzhandler]

You convinced me.
Actually Joel's repo doesn't auto implement INotifyCollectionChanged. The IRevertibleChangeTracking is a 'why not', not mandatory. When building a library it's always good to look around and see what contracts/tools are already there and improve the existing instead of reinventing the wheel (speaking about all those existing ComponentModel interfaces that address this area).

[weitzhandler]

Just ignore my bs commits, I actually committed them in GitHub web. I was laying out the icons in the readme file horizontally.

[mfidemraizer]

I want to stay honest and if I opted-in to don't use IRevertibleChangeTracking and IChangeTracking is because I didn't know that they existed!

Thus, you're absolutely right about your statement: we need to try to use existing work as much as possible to stay DRY. In fact, I'm also maintaining http://designpattern.ninja, and I documented a self-invented anti-pattern called Proud Developer. Check it if you have some time :) I've not published a new article since 23rd of February, but I'm going to publish a new one in the next days, and of course, if you want to publish your own article, pattern or anti-pattern there, feel free to collaborate as it's built on top of Jekyll and you just need git to provide new content with pull requests! See this how-to

Then, I'll look forward for your issue to support those interfaces too ;)

[mfidemraizer]

Check that those interfaces are already supported on .NET Standard 1.3 (https://www.nuget.org/packages/System.ComponentModel/), which is the base .NET Standard version of TrackerDog!! That is, there should be no issue when implementing them as part of TrackerDog 👍

[weitzhandler]

Awesome! Thank you sooooo much!

I hope don't mind me polluting this thread with a question;
Since I'm new to change tracking as unrelated to an ORM, I want to use this because in my Xamarin LoB app I have a huge form with hundreds of fields that all have to be saved to server right when changed (timer enabled), and I want to pass an encapsulation of the changed values in the whole graph to the server, so only what's changed gets saved.
My question is, on the server side (ASP.NET Core WebAPI + EF 6.1.3), is there from your experience an easy way to walk through the graph and apply the changes (assuming passing the changed values would be an the easier part)?