[QUOTE=Sir Rufo;1259345]
Benutzer X darf die Tabellen nur lesen, aber über eine SP darf er doch etwas hineinschreiben.
Und mit meinem bulk load muss ich genau das umgehen.
Das Thema entwickelt ja langsam eine echte Dynamik
Mein Hintergedanke war der, das hier endlich mal darüber gesprochen wird, wie man es richtig macht und nicht immer, das man es so nicht macht
Zitat:
Um es mal vorweg zu schicken,
Genau Begriffe definieren/festklopfen.
1. Testbar = Unittests
2. Mock <> Fake (Mock=nachträgliches Ändern von Verhalten. Fake = Hilfsklasse, um Abhängigkeiten zu kontrollieren)
3. Wartbar = Änderungen ohne Seiteneffekte vornehmen.
4. Robust = Schrotteingaben => wohldefinierte Exceptions. "Keine Überraschungen"
5. Erweiterbar = Erweitern, ohne sich einen Wolf zu tippen.
Zitat:
Schöne Code Beispiele - da sie auf verschiedenen Ebenen einige Fehler aufzeigen.
Sie sind mit Absicht so.
1. Soll das BO die Rechte prüfen? Normalerweise nicht, das macht ein Szenario. Aber wenn die Rechteabfrage systemimmanent ist, z.B. in einer Bank integraler Bestandteil der Aktion ist, dann schon (finde ich). Aber mit Sicherheit nicht so banal wie hier. Insofern => richtig, SRP verletzt.
Zitat:
Zweiter Fall, die Kopplung an die
GUI Daher das 'Command' (in Anlehnung an das ICommand)
Zitat:
Wenn ich nunmal die
VCL verwende, dann ist es auch nicht böse
. Also ich würde mich heute nicht mehr darauf festlegen ob
VCL oder FMX. Unabhängig davon würde ich das trotzdem kapseln (zumindest die Messageboxen), denn diese Interaktion möchte ich erweiterbar gestalten und vor allen Dingen stringent im Design (Kein Mischmasch aus OK/Cancel Yes/No etc. Vielleicht alle Text aus einer Textrepository, d.h. keine 'echten' Texte wg. Übersetzung usw.) Ach, und falls ich doch Abfragen ("Wollen Sie wirklich die Zentrale in die Luft jagen?") und Meldungen ("The HQ was successfully destroyed") testen will, ist so ein Wrapper wirklich sehr nützlich.
Die restlichen Abhängigkeiten.. Nun ja, klar. Da ich vielleicht doch einen "IoC-Container" habe, der das globale Gedöns schön verbirgt, sollte man das noch anständig herunterbrechen können. Nur muss ich mir dann meinen IoC-Container mocken/faken, was auch kein Zuckerschlecken ist.
Allerdings: Das Kommando hat nun einmal diese Abhängigkeiten: Es wird geprüft, gespeichert, gedruckt und interagiert. Und mit DI müsste das dann entsprechend ausarten, weil in meinem Fall das Kommando nun einmal die 'oberste Instanz ist', die die logische Aktion 'TuWas, aber mit allem Drum und dran' ausführt.
Zitat:
Da
imho jede sauber designte Klasse gut (ohne Mocks) testbar ist
Wohl kaum.
Mocks erleichtern nur die Arbeit, sofern ich unter 'Mocking' das gleiche verstehe, wie Du (s.o). Eine saubere (=kleine) Klasse mit DI kommt doch ohne Mocks aus. Ich verwende Mocks bisher nur, weil ich keinen Bock habe, die Abhängigkeiten komplett zu faken. Und da ich in einer Klasse laut Deiner Definition eh nie viele Abhängigkeiten haben kann, ist meine Behauptung auch nicht allzuweit hergeholt. Und die Hintertür ist: Das 'Ohne Mocking' steht in Klammern, weil *festlegen* will ich mich darauf nu auch nich, ne.