Auch wenn das Thema Testbarkeit wahrlich kein neues mehr ist, so gibt es doch immer wieder Neues dazu zu lernen. Die Version 1.0 des Entity Framework (EF) hatte bezüglich der Testbarkeit noch etliche Defizite, die mit der Version 4.0 (und dem kürzlich erschienenen Update auf die Version 4.1) von Microsoft angegangen wurden.

Die große Schwachstelle, über die ich bei der täglichen Arbeit mit dem EF1 häufig stolperte: Die vom Designer generierten Klassen mit dem Ballast aus ChangeTracking und ChangeNotification und der ObjectContext für den Datenzugriff waren eng miteinander verwoben und für UnitTests wenig geeignet.

Mit EF4 kam der Support für Plain Old CLR Objects (POCO) und austauschbare Templates für die Generierung von Entities. Und plötzlich wurde vieles möglich.

In seinem Artikel Testability and Entity Framework erläutert Microsoft MVP Scott Allen detailliert, wie man mit verblüffend einfachen Mitteln aus dem Monolithen Datenzugriff eine durch TestDouble ersetzbare Komponenten macht. Er erklärt, was testbare Komponenten ausmacht. Wie die Patterns Repository und UnitOfWork zusammenspielen und wie man sie zur Kapselung der Datenhaltung einsetzt.

Gut verständlich zeigt er verschiedene Ausbaustufen der Abstraktion vom Entity Framework als Zugriffsschicht. Vom vollständigen Verbergen des Entity Framework hinter der Fassade eines Repository bis zur Verwendung von Interfaces, die das Entity Framework mitbringt. Er erläutert welche Kompromisse bei der Einhaltung von Persistence Ignorance (PI) möglich sind und was man als Gegenwert für diese Kompromisse geboten bekommt. Durch die Verwendung einer Extension-Methode erhält man z.B. die Möglichkeit Fetch-Paths mittels Include() anzugeben (unter EF4.1 funktioniert das auch mittels typsicherer Expressions anstelle von Magic Strings). Die Deklarierung von Properties als virtual ermöglicht implizites lazy-loading und den Komfort von automatischem ChangeTracking ohne dafür selbst Code schreiben zu müssen.

Fazit: Absolut lesenswert! Als großer Fan von einfachen Lösungen für komplizierte Probleme war ich von Scott Allens Artikel begeistert. Der Autor hat es geschafft großen Mehrwert in wenig Text zu packen. Eine halbe Stunde für das Lesen des Artikels. Zwei Stunden um mit den vorgestellten Beispielen zu experimentieren. Und plötzlich kann man ungezählte Arbeitsstunden für manuelle Fehlersuche einsparen.