Change tracking

[simplicbe]

We should decide, whether to enable or not to enable change tracking. Change tracking may hit the performance but would enable to just update the data that has really changed.

Or we could enable and disable change tracking, to just use it when it is required. Furthermore this would enable optimistic locking, if we want to support this.

Also we need to decide, whether any object knows its state or we implement a kind of statemanager. From my point of view, a statemanager would hit the performance more.

Se also #5.

[yvz5]

Just being able to call POCO.SaveChanges() would make developers lives easier but it comes with a price. Which change tracking approach are we gonna use ? change-tracking proxies ? or snapshot change-tracking ?

making change tracking optional would require a lot of engineering hours. it doesnt sound like an easy solution.

if we are going to follow domain driven design, we should implement DTO and POCO seperately and let POCO know its state and implement its behaviour.

[simplicbe]

I'll prefer something like this:

using (var context = DbContext())
{
    var contact = context.Get<IIT_Contact>(new { contactId = 12345 });
    contact.FirstName = "Max";
    context.Submit();
}

EDIT: Using a context makes db transactions easier.

Because then we keep all information in a scope and models are more lightweight. Our models which are compiled by roslyn can't be simple pocos because the might contain some table information and there own fill logic. We've made some performance benchmarks in the past and this was the most performant solution. Or we let Roslyn precompile some parts of the change tracking to be more performant than using snapshots via serialization or something similar.