nicht angemeldet
Hallo King^Lully,
Zuerst Danke für die Antwort.
Ihr habt Datenzugriff und Logik in die SPs gepackt, weil Logik und Datenzugriff schwer zu trennen ist.
Ja, das ist ja an sich der klassische Ansatz.
Ihr bekämt dann eine zusätzliche Schicht, die die Geschäftslogik und den Datenzugriff trennen würde.
Ist das nun gut oder schlecht?
Die Idee ist, in der Geschäftslogik mit Objekten zu arbeiten, die dann von einer Persistenzschicht in die Datenbank geschrieben wird.
Bei SPs hat man ja die Situation, dass man, wenn man die Funktionalität in kleinere Einheiten aufteilt (um beispielsweise das Code-Duplizieren zu vermeiden), diese in sich konsistent halten sollte. Was allerdings bedeutet, dass man in diesen Prozeduren sehr viele Kostistenz- bzw. Kontextprüfungen durchführt. Die SPs neigen dann dazu dass der meiste Code Prüfaufgaben hat und die eigentlichen Arbeitsanweisungen (die dann den Datenbestand bearbeiten) eher in dem Prüfcode untergehen. Die Alternative dazu wäre, dass man in Oracle entweder mit Object-Typs arbeitet oder aber sehr viele Übergabeparameter braucht.
Wir erwarten uns von dem OO-Ansatz, dass der Prüfauwand kleiner wird, bzw. besser von der eigentlichen Funktionalität trennen kann, weil Objekte (entsprechend gut designed und programmiert) in sich immer konsistent sein sollten.
Datendesign ist per se objektorientiert und objektbeziehungsorientiert. Ich wäre mit "OO und dann happy" vorsichtig.
Natürlich wissen wir, dass OO alleine noch nicht das allein seeligmachende ist;-)
SPs sind "eigentlich" gar nicht so schlecht wartbar, das Problem ist nur den Gesamtüberblick zu behalten.
Du hast recht, genau das ist derzeit unser Problem.
BTW - was soll sich vereerben? Entitäten sind sich zwar oft ähnlich, aber "Vererbung" macht es oft nicht leichter, eventuell ein Daten-Redeign in Betracht ziehen?!
Eine Anwendung, so wie wir das im Kopf haben, besteht eben nur zum geringeren Teil aus Entitäten. Eine Menge Funktionalität wäre in sog. Controller-Klassen unterzubringen, die dann mit den Entitäten umgehen. die Entitäten und deren Beziehung zueinander ist eigentlich fast immer konstant bei den einzelnen Projekten. Lediglich Attribute können dazukommen (wobei diese meist nicht aktive Attribute sind, sondern eher für Reports und ähnliches benötigt werden).
Die gravierenden Änderungen sind meist in den Funktionen, die mit diesen Entitäten arbeiten. Und hier kommt es oft vor, dass man diese Funktionalität von der bestehenden ableitet und nur an den notwendigen STellen modifiziert. Und da machen sich OO-Ansätze wie Vererbung oder Interfaces usw. an sich recht gut.
Liest sich ganz gut. Aber wo ist die Datenhaltung? ;)
Das soll eine Persistenzschicht wie z. B. Hibernate erledigen.
"Applikationserver" sind letzlich auch nur Komponenten, ich kenne den Java-Jargon auch nicht so recht, aber mich haben bzgl. Java hier im Forum einige Leute abgeschreckt.
Mein Problem ist, dass ich noch nicht sehen kann, wie diese Applikationsserver unsere Art von Anwendung verarbeiten können, da ich den Verdacht habe, dass diese Teile eher mit einem Webserver zu vergleichen sind als mit einer echten Server-Anwendung. Vor allem das Batchprozessing ohne Anstoß von aussen sehe ich noch nicht umsetzbar.
Stell mal irgendwo ne Grafik ein und eine Datendesign-Skizze, zumal täten die Komponenten interessieren. Auserdem Prjektumfang, zu erwartende Last und der Abnhemerkreis.
Datendesign gibt es noch nicht. Es geht an sich um ein Logistik-System das Aufträge usw. verarbeitet. Bezüglich der Last ist das auch so eine Sache, da ich hier zu wenig über die eigentliche Natur der Anwendung sagen kann. Nur so viel, dass mind. 150-200.000 Aufträge täglich über das System laufen sollen. Das klingt vielleihct etwas wenig, allerdings ist es die interne Verarbeitung dieser Aufträge, die sehr aufwendig sein kann.
Grüße
Klaus