Na da habe ich ja was ausgelöst heute Morgen ;-). Grundsätzlich ist das Feedback richtig und ich denke auch, dass hier ein allgemeiner Konsens herrscht. Hätte ich die Anwendung, für die ich das Problem vermeintlich gelöst habe, auch einmal live ausgeführt, hätte ich den Code so wahrscheinlich auch nie veröffentlicht, da es mit dem Null-Result schon bei der ersten Verwendung gekracht hätte (übrigens ein netter Nebeneffekt loser Koppelung und der test-getriebenen Entwicklung: ich schraube ...
Neulich bin ich nach langem Grübeln und einigem Hin- und Her für mich zu dem Schluss gekommen, dass Repositories für mich in den allermeisten Fällen nicht testwürdig sind. Ganz glücklich war ich mit diesem Ergebnis nicht, aber irgendwann muss man ja auch einmal einen Platz im Dorf für die Kirche finden, um sie dann da stehen zu lassen – zumindest für das aktuelle Projekt. In den Kommentaren regte sich Widerspruch, insbesondere Stefan brachte mich dann auf die „richtige Spur“.
Das ...
Um Abhängigkeiten und unerwünschte Seiteneffekte zu vermeiden setze ich bei meinen Repositories in aller Regel darauf diese nach außen hin abzugrenzen. Das bedeutet, dass ich beispielsweise auf IEnumerable<> verzichte und stattdessen immer List<> verwende.
Das hat zwar auch ein paar Nachteile (Kein Austausch der Implementierung im Vgl. zu IList<>, kein Lazy-Loading usw.) aber eben auch Vorteile - insbesondere den, dass alle Queries gegen die Datenbank ausgeführt werden, ...
Wie ich aktuell test-getrieben entwickle habe ich kürzlich in diesem Post beschrieben. Was ich darin verschwiegen habe ist, wie ich meinen Datenzugriff teste.
Den Zugriff auf die Daten einer Anwendung kapsele ich in Repositories. Dies verhindert Abhängigkeiten zu und von anderen Teilen der Anwendung und sorgt für eine 100% einwandfreie Trennung, da alle anderen Komponenten nur gegen ein Interface arbeiten:
1: public interface ICompanyRepository
2: {
3: ...
Ist doch selbstverständlich, oder? Scheint nicht so, zumindest nicht, wenn man den vielen Ansätzen von Microsoft folgt. Da gibt es seit ASP.NET 1.0 die Validation Controls für WebForms und mit ASP.NET MVC hielt eine Validierung über DataAnnotations Einzug. Letzteres ist auch verdammt sexy, da die Konfiguration über Attribute wirklich schön sauber ist. Deshalb habe ich es im ersten MVC-Projekt auch versucht zu verwenden.
Mir ist das Ganze aber ziemlich schnell auf die Füße gefallen. Von ...
Vor etwas über einem Jahr habe ich mir einen Ruck gegeben und mein erstes Projekt vollständig test-getrieben entwickelt. Nach etwa 6 Wochen Projektlaufzeit hatte ich rund 400 Unit-Tests geschrieben und eine Anwendung ausgeliefert, die so gut wie fehlerfrei war.
Ich habe mir einiges an Material zu TDD reingezogen, das Video von Gabriel Schenker war wohl am hilfreichsten für den Start (kann ich jedem empfehlen). Trotzdem verlief der Start recht holprig, was in meiner Erinnerung vor ...
Am Wochenende fand in Nürnberg das zweite Barcamp nach 2006 statt. Was soll ich sagen: es war ein sehr spannendes, abwechslungsreiches und durchaus auch lehrreiches Wochenende inmitten netter Leute.
Der Rahmen des Nürnberger Südwestparks war durch die hellen, offenen und großen Räume sehr passend, die Organisation einwandfrei und die Session-Themen hatten für mich persönlich genau den richtigen Mix aus Technologie und Business (u.a. war ich in Cloud Computing, Prozessmanagement für Startups, ...
Da habe ich mich gestern lang und breit damit beschäftigt, wie man das Problem auf Property-Basis lösen kann, dann das. Das gezeigte Beispiel funktioniert zwar in der Theorie - und auch in den Tests - nur in der Praxis fällt es durch. Problem: "validationContext" ist null. Immer.
Ich stecke noch nicht so tief drin, als das ich wüsste, warum Microsoft das nicht implementiert hat - aber da wir ja von einem Release Candidate sprechen, nehme ich mal an, dass sich da in absehbarer Zeit ...
UPDATE
Ein Standard-Fall im Web ist die Eingabe von Passwörtern für Registrierungs-Formulare. Damit man auch (weitestgehend) sicherstellt, dass das eingegebene Passwort keine unbeabsichtigten Tippfehler enthält, lässt man es den Nutzer üblicherweise einfach doppelt eingeben - und vergleicht das Ergebnis dann bei der Überprüfung. Hat er zweimal das gleiche Passwort eingegeben, ist alles in Ordnung.
Die vorhandenen Attribute sehen diesen Fall aber leider nicht vor, weshalb man sich sein eigenes ...
Die neue Vorgehensweise beim Validieren von Daten über View Models und Attribute erfordert auch eine kleine Umstellung bei der test-getriebenen Entwicklung (TDD).
So kann man zwar weiterhin die Controller-Action auf die Anforderungen hin testen, etwa ob der ModelState ungültig ist, wenn eine per Attribut deklarierte Bedingung an ein Element des View Models nicht erfüllt ist (z.B. "required"), aber eigentlich ist das der falsche Ort - viel mehr sollte man das View Model selbst ...
