Blinder Fleck Change Tracking

Habe grad ein paar Postings zum Thema Distributed Domain Driven Design (DDDD oder “D4”?) gelesen. Dabei ist mir wieder der Gedanke gekommen, dass wir uns das Leben noch schwerer machen als nötig. Ich glaube nämlich, zu unserem Glück fehlt uns noch eine deutliche Separation of Concerns (SoC).

Über das DataSet kann man sagen, was man will, es hat eins ganz wunderbar getan: Änderungen verfolgen. DataSet mit Daten füllen, irgendwohin schicken, dort ändern – und dann nur die Änderungen zurückschicken, um sie zu persistieren. Sehr cool!

Und dann kam O/R Mapping – und wir haben für die Änderungsverfolgung (Change Tracking) einen Blinden Fleck entwickelt. Denn entweder haben O/R Mapper kein Change Tracking betrieben, sondern Daten geladen, Objekte befüllt und dann einfach immer komplette Objekte auch wieder gespeichert, wenn man ihnen sagte, dass sich daran etwas geändert hat. Oder sie haben Objekte befüllt, die intern selbst Buch führen über Änderungen an sich. Dann konnte der O/R Mapper später ohne manuelle Meldungen über Änderungen sich selbst geänderte Objekte herauspicken und mit minimalen SQL DML-Statements persistieren.

Klingt bequem, ist bequem. Aber Change Tracking liegt im Blinden Fleck. Wir sehen das nicht. Meistens. Deshalb machen wir uns darüber keine Gedanken. Sollten wir aber. Denn letztlich ist das ein Thema, das immer relevant ist, wenn Mapping ins Spiel kommt.

Deshalb hat mich ja auch D4 wieder darauf gebracht. In verteilten Systemen erzeugen wir nämlich Objekte z.B. in einem Server, die wir zum Client schicken. Ob der Server die aus einer Datenbank befüllt oder nicht, ist egal. Änderungen an diesen Objekten im Client sollen dann wieder zurück zum Server. Aber wie? Geänderte Objekte können in Form “dummer DTOs” eigentlich nur komplett zurückfließen. Aber warum soviel Traffic? Warum können wir nicht nur die Änderungen zurückschicken und in die serverseitigen Instanzen einspielen?

Klar, das geht. Kann man programmieren. Kostet aber Mühe. Event sourcing ist dazu ein Stichwort. Aber warum sollten wir das immer wieder programmieren? Das ist ein so grundsätzliches Problem, dass ich finde, dafür sollte es eine allgemeine Lösung geben.

Und die steckt für mich im Change Tracking, das manche O/R Mapper eh schon tun. Warum wird dieses Change Tracking nicht dort rausgezogen und separat implementiert? Warum gibt es nicht eine Change Tracking Infrastruktur (z.B. auf einem AOP-Fundament), die dann beim O/R Mapping oder auch bei sonstigem Mapping oder Versand von Daten einsetzen kann?

Für mich sind Change Tracking und Persistenz inzw. ganz klar orthogonale Belange. Sie sollten deshalb auch technologiemäßig ganz klar getrennt werden.  Change Tracking darf nicht unser Blinder Fleck sein.

Wer baut also als erstes eine allgemeine Change Tracking Infrastruktur z.B. auf der Basis von PostSharp? Wer baut einen O/R Mapper, der dann darauf aufsetzt? Das macht dem O/R Mapper-Hersteller weniger Mühe. Und das verschafft dem Change Tracking-Hersteller eine viel größere Zielgruppe. Alle würden profitieren.