Softwarearchitektur: Geschichtet oder begegne mir nicht

[Hernan Cortez]

 

letzte Woche war da wieder so ein Fall wo über ein Domino Frontend ein Endanwender durch eine vermutlich in dieser Kombination "verbotenen" Abfolge von Aktionen einfach mal so einen Stammdatensatz von KUNDENDATEN aus einer angedockten DB2-Datenbank löschte.
Ist der Endanwender Schuld: HELL NO. Die Anwendung darf sowas nie zulassen, ohne jede Diskussion.

Wenn ich mit sowas konfrontiert werde, stösst das mich immer in eine gefährliche Mischung aus Aggression, Wut und Verzweifelung. Sowohl in .NET als auch in J2EE ist es klar: Das Frontend spricht mit dem Business Layer der Business Layer spricht mit den Backend Systemen (RDBMS, SAP, Host). Alles andere wird als im Grunde genommen nicht kontrollierbarer Wahnsinn angesehen. Es sei denn, es gibt einen der alle 25 Jahre auftauchenden Sonderfälle, wo es anders gemacht werden muß.

Habs nicht zum ersten mal erlebt, dass dies auf kreativen Groupware-Plattformen nicht so gemacht wird. Da wird so'n Kundendatensatz eben mal im querysave gelöscht, wenn FeldX im Dokument auf einen bestimmten Wert steht. Hat ja im Test supi gefunzt.

Code

Rem log nothing and have a nice weekend.  
if doc.FeldA(0) = "wert" then call thisFancyBigDestroyerFunction(doc.KDNR(0))
Rem log nothing and have a nice weekend.  

FeldA besitzt eine komplexere Formel und kann irgendwie durch den User zur Verfügung stehenden Agenten oder sonstwas umgeswitcht werden.

Ich hatte noch Glück, dass ich das hinreichend belegen konnte, dass die Operation von einer Anwenderin ausgelöst wurde und zwar nur durch das letzte Änderungsdatum eines bestimmten Dokuments (Glück) und doch verhandene Logs im Kontext des DB2 Zugriffs aus Notes-Agenten (die dann aber leider mit Server-Berechtigung laufen). Sowie die Zeitstempel dieser verstreuten Log-Spuren.

Da sind wir einer Meinung, dass das coden von sowas einen Fall von gravierenden anti-sozialen Verhalten von Seiten des Programmierers darstellt, oder?

Irgendwelche Gegenmeinungen  

Gruß Axel

[animate]

ich verstehe noch nicht ganz, was das mit Schichten zu tun hat. sowas kann doch auch mit Schichten passieren.
Erklär mal bitte...

[Hernan Cortez]

ich verstehe noch nicht ganz, was das mit Schichten zu tun hat. sowas kann doch auch mit Schichten passieren.
Erklär mal bitte...

Hi

In Schichten, v.a. wenn sie vernünftig dokumentiert sind, habe ich klare Wege eines Löschbefehls vom Userfrontend durch Schichten von Klassen bis zum Absetzen des SQL-Statements. Da ist es dann relativ einfach in diesem Pfad die geeigneten Schranken und logs einzubauen. Zumal die Kommunikation zwischen den verschiedenen Klassen durch Access Modifier beschränkt werden kann.

Manche Domino-Anwendungen haben den Aufruf zum SQL-Befehl im QuerySave irgendeiner halbvergessener Teilmaske. Das ganze wird wie gesagt dann ausgeführt, wenn ein bestimmtes Feld den Wert "X" hat. Auf welche Wege dieser Wert "X" gesetzt wird, ist inzwischen auch schon nicht mehr so präsent. Schliesslich wird ja von 4 Masken, 5 Agenten, 2 Scriptlibrary und 1 Ansicht Feldwerte in Dokumenten dieser Maske geändert. Access Modifier "braucht" man ja in Domino nicht, um Zugriffe auf Properties von Entities (=Dokument) zu kapseln.  Ach ja. Und die Änderung des Feldwertes kann ja nicht nur über das Feld geschehen. Nein. Nein. Das ist ein berechnetes Feld mit einer supi-effizienten Formel, deren Ergebnis wiederum von 4 anderen Feldern abhängt. Einer davon ist ein DBLookup...
Irgendwie gibts da wohl auch noch son paar persönlichen Agenten, die man bestimmten Anwendern bei Problemen in der Testphase zur Verfügung gestellt hat, um das System wieder schnell funktionsfähig zu machen. Gelöscht wurden die dann nicht. Vielleicht braucht man die ja noch mal.

Genau das.

Bestimmt sind nicht alle Domino-Anwendungen so. Aber unter den Bedingungen knapper Zeit, sich oft ändernder Requirements von Seiten der Anwender, etc. öfter als mir Recht ist.

[animate]

Bestimmt sind nicht alle Domino-Anwendungen so. Aber unter den Bedingungen knapper Zeit, sich oft ändernder Requirements von Seiten der Anwender, etc. öfter als mir Recht ist.

Tröste dich, es geht nicht nur dir so.
Ich sehe das Problem aber eher woanders.
Knappe Zeit und sich ändernde Anforderungen sind ja eigentlich Standard. Ich zumindest habe noch fast kein Projekt erlebt, wo es nicht so ist.
Ich denke, dass Notes-Anwendungen dazu verleiten, eine suboptimale Architektur zu entwerfen.
Hmm, das ist ja genau das, was du in deinem Posting auch geschrieben hast.
Naja, und genau das ist, denke ich, das Problem.

[eknori]

Müsste man dann so weit gehen und selbst bei einem Managermit Löschberechtigung die Applikation prüfen lassen, ob ein Löschen "sinnvoll" ist, oder ob datenbankinterne Hindernisse dieses Löschen zum jetztigen Zeitpunkt nicht ratsam machen.# ?

Ist ein interessantes Thema

Ulrich

[Hernan Cortez]

Müsste man dann so weit gehen und selbst bei einem Managermit Löschberechtigung die Applikation prüfen lassen, ob ein Löschen "sinnvoll" ist, oder ob datenbankinterne Hindernisse dieses Löschen zum jetztigen Zeitpunkt nicht ratsam machen.# ?

Kommt auf den Wert der Daten an. Die ist hier wirklich hoch (ohne näher darauf einzugehen).
Der Lösch-Zugriff auf solche Daten sollte im Code möglichst zentralisiert sein. J2EE- und .NET best practices betonen stärkstens eine geschichtete Architektur. Geschichtete Architektur führt zu zentralisierten Zugriffen auf die BackendSysteme.
Ein DELETE-Request auf wertvolle Daten sollte zumindest zweifelsfrei gebunden an den Auslöser geloggt werden.
Das sind wie gesagt Zugriffe auf ein Fremdsystem (DB2).

[Gandhi]

Meckern kann man ja immer.
Wie könnte man es denn - mit Notes besser machen?
Das ganze über Schichten abwickeln....im Grunde nicht möglich.

Wie wäre es, die Dokumente zu verstecken (statt zu löschen) und dann einen Agenten (z.B. einen Web-Agenten) als 'Schicht' eben für eine bestimmte Aufgabe zu nutzen....und im Fall DB2 wäre dann noch interessant: Wie macht man einen Roll-Back... ;-)

Richtige Schichten bekommt man meines Wissens mit Domino hin (es sei denn über die Servlet Engine? War da nicht mal irgendwie Tomcat integriert).

Domino ist in meinen Augen als Werkzeug so was wie ein Akku-Schrauber. Schnell, flexibel und für vieles zu brauchen. Aber eben auch nicht für alles. Noch nicht mal Löcher in Beton bohren kann man damit...

Somit ist klar, dass das für solche Anwendungen - sagen wir mal - eine suboptimale Plattform darstellt. Mit der wachstenden Integration in die Welt der Java Applikationsserver wird dies sich dann wohl etwas reduzieren. Im Moment muss man einfach hin und wieder den Mut haben bestimmte Dinge mit Notes nicht zu machen.