.netstandard version?

[Blastnsmash]

Reminder to investigate .netstandard compatibility.

My primary interest is to keep libraries we use compatible with xamarin for ios and android development.

https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

[mfidemraizer]

@Blastnsmash Hey!

Thank you for the effort of posting the issue ;)

Ok, I'll take a look at this as soon as I've a ported everything to .NET Core (I believe that this will be closer to .NET Standard than a full framework version like we've right now...).

The support is very tied to Castle Core support to .NET Standard.

[mfidemraizer]

@Blastnsmash

I'm glad to say that I've been able to run the tests on .NET Core 1.1 using a .NET Standard library of TrackerDog.

If I'm not mistaken, you need a .NET Standard 1.6-based TrackerDog, right? I've checked .NET Standard's matrix here and both Xamarin flavors are already supported on .NET Standard 1.6.

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

[Blastnsmash]

Very cool.
Currently, our team is looking into n-tier development with Entity Framework. I'll let you know if we use TrackerDog in the future.
Keep up the good work :)

[mfidemraizer]

@Blastnsmash Nice! Thank you.

In fact, my motivation to implement TrackerDog was based on being able to mimic what a full-fledged OR/M does in terms of change tracking like NHib or EF do but with MongoDB as storage. Since I didn't want to spread Mongo specific API to persist and query data, and at the end of the day I also wanted to architect a true separation of concerns, I felt that change tracking shouldn't be coupled with the concrete data mapping layer.

So I ended up implementing TrackerDog to support 100% agnostic domain transactions and units of work.

About your scenario, may you elaborate more on this? Do you expect to transfer a change-tracked object across physical boundaries? This isn't supported in TrackerDog, but I'm thinking how we could achieve this feature and my first bet could be something like this:

// Some tier
// ChangeTrackingInfo could be a serializable DTO containing
// current state of change tracking of a given change-tracked object!
var changeTrackingInfo = someObject.ExportChanges();
// We would serialize changeTrackingInfo as JSON...

// Some other tier
var x = new Some();
// The following method would import change tracking info from another tier
// into an instance of the same object in the current tier
x.ImportChanges(JsonConvert.DeserializeObject<ChangeTrackingInfo>(changeTrackingInfoJson));

What do you think about this?

[Blastnsmash]

What do you think of http://trackableentities.github.io/ approach?

It uses T4 templates to generate the client and server code and extends entity framework with a merge option.

[mfidemraizer]

@Blastnsmash It's interesting, I've never heard about this project. It's an absolutely different approach compared to what TrackerDog does.

Clearly it's a solution that's built for Entity Framework, but I guess that it should be usable as a standalone solution to track object graph's changes like TrackerDog does.

My opinion is that I would avoid code generation. I don't like it because you need to deal with workarounds to extend generated code, and you can get stuck once the library author doesn't release extensions to newer Visual Studio versions.

For me, the best alternative to AOP using proxies is using an IL weaving/post-compilation tool like PostSharp or Fody.

Probably IL weaving approach is the best of all possible ones, because it injects change tracking logic during compilation and it doesn't pollute your code with auto-generated code. In contrast to the TrackerDog approach, IL weaving has a smaller performance footprint.

In the opposite side, TrackerDog's approach of using runtime code generation with Castle Core / DynamicProxy has the advantage that you don't need extra build steps nor Visual Studio extensions.

IMHO, again, the best approach is the IL weaving one. If I would have more spare time, I would implement TrackerDog with Fody... it would be the definitive solution!

[mfidemraizer]

@Blastnsmash .NET Standard library is already published on NuGet! Finally, if your team ends up using TrackerDog, I'll be happy to fix any bug you may find while using it.

[weitzhandler]

@mfidemraizer I'm reading up this thread and every comment you make is something I came across today and thought about, especially in relation to trackerdog.

I actually AM using PropertyChanged.Fody and shared POCO entity classes.
Having TrackerDog work as a post compilation emit would be awesome.

Though what I see more important (as I mention here), is a means of transferring graph-change data, and a convenient way to recurse through the graph bottom up to any depth.

I'm sure EF-specific or even EF-biased stuff should remain out of TrackerDog, but it'd be a great having a TrackerDog.EntityFramework repo that actually accepts a TrackerDog change-data and saves into DB. That can be a messy project especially when maintaining references add/remove/delete/orphans etc., but has great potential of helping a lot of people.
Anyway, first thing off we'd need some (json?) wrapper to be able to transfer change data.

[mfidemraizer]

@weitzhandler Right, IL weaving should be awesome... BTW while I would love to give that approach a try, my main issue now is I don't have enough time to overcome this migration...

About the Entity Framework thing, it would be wonderful, but again I don't have enough time for this. At least, for now.

Finally, about the changed data graph and transferring it over the wire, will you open another issue so we can discuss it accordingly?