nicht angemeldet
Hallo,
die eigentliche Logik des Datenmodells (Konsistenz der Daten sichern, den jeweils notwendigen Objekt-Teilgraphen auswählen, etc.) sollte definitiv in der Datenbankschicht implementiert werden.
Genau da gibt es ja die zwei Konzepte "Alles in der DB" und "die DB ist nur ein dummer Storage von Daten".
Wie weiter unten schon erwähnt habe, soll die Datenbank über eine Persistenz-Schicht (Hibernate oder Toplink oder ähnliches) verwaltet werden. Das bedeutet letztendlich dass die Datenbank an sich im hier diskutierten OO-Konzept eine untergeordnete Rolle übernimmt und nicht, so wie beim PL/SQL-Ansatz, die Hauptrolle spielt.
Diese Logik brauchen alle auf der Datenbank aufbauenden Anwendungen (falls es mehrere geben sollte, wobei man sich darüber streiten kann, ob das gut ist), es ist meist wesentlich Performanter, das in der Datenbank zu erledigen und es macht Anwendungen meist unübersichtlich, wenn man diese Logik aus dem Datenmodell, das nunmal in der DB liegt, herauszieht.
Ist es nicht so, dass wenn man eine Sammlung von Entitäts-Objekten, die dann persistiert werden können, in seinen Anwendungen verwendet, die Logik in der Datenbank praktisch vollständig entfallen kann?
Die Performance ist eine andere Geschichte. Betrachtet man nur den Datenzugriff und dessen Ausführungsgeschwindigkeit, so ist die DB sicherlich unschlagbar.
Andererseits ist ein Aspekt der Softwareentwicklung auch die Performance bei der Entwicklung selbst bzw. die Anpassungsfähigkeit eines Softwaresystems, wie das von dem wir hier reden. Das dabei auhc kommerzielle Überlegungen eine Rolle spielen sollte eigentlich auch klar sein.
Ein Zeil des Redesigns unserer Software ist es eben auch, dass wir schlagkräftiger bei der Umsetzung von Kundenprojekten und den damit verbundenen Anpassungen werden.
Bei vielen Wirtschaftsanwendungen gibt es darüber schon gar keine Geschäftslogik mehr sondern nur noch eine Präsentationsschicht. Wenn es keine gibt, sollte man sich auch keine ausdenken ;-)
Da ahben wir anscheinend unterschiedliche Erfahrungen gemacht, vorausgesetzt ich haben Dich richtig verstanden.
Gibt es welche (Anbindung anderer Systeme, Realisierung irgendwelcher Arbeitsabläufe, komplexere Auswertung der Daten also im Sinne von irgendwas Simulieren/Berechnen (eher selten nach meinem Eindruck in der Wirtschaft)) dann ist eine Zwischenschicht, die das erledigt, und nicht in der Datenbank implementiert ist, sinnvoll.
Genau die von Dir genannten Beispiele sind unser tägliches Brot. Und ich denke doch dass wir eine eher typische Wirtschaftsanwendung entwicklen.
Nun stellt sich die Frage, in welcher Technologie man das tut. Nachdem ich nun etwas C# verwendet habe, scheint mir Java angenehmer, weil die Klassenbibliothek ausgereifter ist. Das fängt schon mit Datenstrukturen an, bei .NET fehlt einfach einiges.
Kannst Du das genauer erklären? Ich habe auch das Gefühl, dass Java serverseitig weiter ist, aber GEfühl alleine reicht hier nicht.
Für C# spricht allerdings sehr stark, dass ihr Euch damit auskennt und dass ihr schon ein Teil der Anwendung damit realisiert habt.
Du sagst es.
Eine weitere Sprache verhindert effektiv die Wiederverwendung bestehenden Codes.
Die Wiederverwendbarkeit von Code ist nebensächlich, da das bestehende C#-System eine vollkommen andere Aufgabenstellung hat (es ist unser GUI-System). Eigentlich ist eine weitgehende Entkoppelung des GUI-Systems von der hier besprochenen Anwendung sogar gewünscht, da das GUI-System eine recht generischen Ansatz verfolgt.
Außerdem ist die Kommunikation in heterogenen Anwendungen praktisch immer etwas umständlicher zu handhaben.
Das ist uns bewusst. Allerdings sollen gerade mit dem GUI-System eher primitive Datentype ausgetauscht werden (also Strings, div. numerische Typen, Datumswerte usw.) da das GUI-System stark auf den ADO.NET-DataTables beruht.
Was Application-Server, Komponentenkonzepte (JEE) usw angeht, würde ich vorsichtig sein. Diese Dinge haben alle ihren Zweck und sind hilfreich, allerdings nur, wenn man sie auch versteht und das kostet Zeit und Aufwand.
Wenn ihr also nicht die Zeit oder das Geld habt, Euch in komplexe, neue Technologie einzuarbeiten, kann es besser sein, es zu lassen.
Da es sich bei dem Redesign um eine grundlegende Richtungsentscheidung handelt, ist der Aufwand für die Einarbeitung nicht so bestimmend, so lange es sich nicht um mehrere Mannjahre handelt;-) Aber so im Bereich von einigen Monaten darf das durchaus liegen. Und seien wir uns ehrlich, irgendwann haben wir uns ja auch das erste Mal mit SQL bzw. SPs auseineandersetzen müssen. Und das versteht man auch nicht vom ersten Tage an.
Nichts versaut eine Architektur eines Systems meiner Meinung nach zuverlässiger, als Technologie, die man nicht verstanden hat.
Wie wahr. Deshalb wollen wir die Entscheidung auch nicht von jetzt auf gleich treffen. Wir versuchen eher, so viel von der Technologie wie möglich zu verstehen, bevor wir damit die eigentliche Umsetzung beginnen.
Grüße
Klaus