Datenbankanwendung und Klassen - sinnvoll?

[süden]

Hallo,

ich liebäugel schon lange mit Klassen (nicht lachen bitte),
und habe ein schlechtes Gewissen, weil ich noch keine selbst gebaut habe.

Ich würde aber gerne. Sonst bin ich ja kein Echter sondern nur ein Fummler.

Bisher habe ich: Komponenten drauf, paar Zeilen Code - fertig. Nix Klassen usw.
Ist es sinnvoll, und wenn ja, wie mit Klassen zu arbeiten?
Mein Hauptprogramm ist schon ganz schön umfangreich, und nur noch schwer zu händeln.

[Furtbichler]

Könntest Du bitte den kleinen Rechtschreibfehler in der Überschrift korrigieren, sonst fall ich noch um vor Lachen. Danke.:-D

[süden]

Besser so?

[BUG]

Zitat:

Zitat von süden (Beitrag 1242927)

Ist es sinnvoll, und wenn ja, wie mit Klassen zu arbeiten?

Ja! Die Frage, wie man mit ihnen am besten programmiert, ist kniffliger:
Allein mit der klassischen bzw. Pflicht-Literatur zu dem Thema lässt sich leicht ein kleineres Bücherregal füllen.
Das lässt sich nicht in mal eben so in einer Diskussion klären.

In letztem Thread zu dem Thema wurde als gutes Buch "Objektorientierte Programmierung" empfohlen.

[Furtbichler]

Vielleicht so viel zum Anfang bzw. Grundverständnis.

Man kann grob zwischen prozeduraler und OO Programmierung (Klassen) unterscheiden.

Wir haben Daten, z.B. Kunden. Und Operationen damit, z.B. 'Laden','Speichern', 'Umzug' etc.

Prozedurale Programmierung

Delphi-Quellcode:

Procedure LadeKunde (Kunde : TKunde; Kundennummer : String);
Procedure SpeichereKunde (Kunde : TKunde);
Procedure Umzug (Kunde : TKunde; NeueAdresse : TAdresse);

OO (Objektorientierte) Programmierung

Delphi-Quellcode:

Kunde.Lade(Kundennummer : String);
Kunde.Speichere();
Kunde.Umzug(NeueAdresse : TAdresse);

Vorteil: Die Operationen auf den Daten sind geordnet an einer Stelle.

Der Rest von OOP ist eigentlich genauso wie der Rest von Old-fashioned Programmierung: Ordnung, Struktur, Sauberkeit.

Ohne Bücher und Praxis kommst Du nicht weit. Aber wie beschrieben, kannst Du schonmal anfangen.

[mkinzler]

Wobei Komponenten ja auch Klassen sind. Ich vermute er meint eher etwas wie ORM.

[Furtbichler]

Zitat:

Zitat von mkinzler (Beitrag 1242955)

Wobei Komponenten ja auch Klassen sind. Ich vermute er meint eher etwas wie ORM.

Zitat:

Zitat von süden (Beitrag 1242927)

ich liebäugel schon lange mit Klassen (nicht lachen bitte), und habe ein schlechtes Gewissen, weil ich noch keine selbst gebaut habe.

Und ich vermute, er meint Klassen allgemein.

PS: Klassen verwenden und Klassen schreiben sind dann doch 2 Paar Schuhe.

[mkinzler]

Im Titel bezieht er sich aber auf Datenbankanwendungen

[Sir Rufo]

Und der Kern der Frage ist doch die Klasse.

In anderen Worten

Zitat:

Soll ich mich mit dem Thema Klassen auseinandersetzen, wenn ich mit einer Datenbank arbeiten möchte?

Das mit dem ORM ist dann sekundär ... ;)

[DeddyH]

Könnten wir uns nicht einfach darauf einigen, dass OOP-Kenntnisse für ein ORM elementar sind?

[MrSpock]

Zitat:

Zitat von DeddyH (Beitrag 1242962)

Könnten wir uns nicht einfach darauf einigen, dass OOP-Kenntnisse für ein ORM elementar sind?

Ich glaube schon. :-D

Ich habe mein Studium 1988 abgeschlossen. Da war das funktionale Zerlegen eines Problemfeldes angesagt. Meine Diplomarbeit ist ein umfangreiches Programm gewesen, in dem ich die Funktionale Zerlegung sehr gut umgesetzt habe. Aber schon damals hat mich gestört, dass Daten nicht so "sauber" behandelt wurde. Als dann OOP aufkam und ich auch viel darüber gelesen hatte, hat es dennoch fast 2 Jahre gebraucht, bis ich den Paradigmenwechsel auch wirklich vollzogen habe. Ich habe einfach bei Problemlösungen nicht in Objekten, ihren Eigenschaften und Methoden gedacht, sondern anfangs nur in Funktionen. Man muss nämlich bereits ganz früh im Design in Objekten denken.

Aber auch ein anderer Aspekt hat mich damals wie hier in der Fragestellung beschäftigt: Wenn ich eine relationale Datenbank habe, in meinem Programm aber mit Objekten arbeiten will, muss ich dann tatsächlich ein Objekt definieren und beim Einlesen der Daten, diese in ein Objekt kopieren? Soll man also Klassen für Datensätze definieren? Wenn die Fragestellung hier so gemeint ist, ist sie sicherlich interessant.

[fkf]

Zitat:

Aber auch ein anderer Aspekt hat mich damals wie hier in der Fragestellung beschäftigt: Wenn ich eine relationale Datenbank habe, in meinem Programm aber mit Objekten arbeiten will, muss ich dann tatsächlich ein Objekt definieren und beim Einlesen der Daten, diese in ein Objekt kopieren? Soll man also Klassen für Datensätze definieren? Wenn die Fragestellung hier so gemeint ist, ist sie sicherlich interessant.

Genau das ist meine (ungelöste) Frage, die ich bisher (aus Bequemlichkeit/Unkenntnis) immer mit "Nein" beantwortet habe.
Eine vertiefende Diskussion (inkl. prakt. Vorgehensweise/Beispielen) wäre super.

F.F.

[Lemmy]

Zitat:

Zitat von fkf (Beitrag 1242965)

Zitat:

Aber auch ein anderer Aspekt hat mich damals wie hier in der Fragestellung beschäftigt: Wenn ich eine relationale Datenbank habe, in meinem Programm aber mit Objekten arbeiten will, muss ich dann tatsächlich ein Objekt definieren und beim Einlesen der Daten, diese in ein Objekt kopieren? Soll man also Klassen für Datensätze definieren? Wenn die Fragestellung hier so gemeint ist, ist sie sicherlich interessant.

Genau das ist meine (ungelöste) Frage, die ich bisher (aus Bequemlichkeit/Unkenntnis) immer mit "Nein" beantwortet habe.
Eine vertiefende Diskussion (inkl. prakt. Vorgehensweise/Beispielen) wäre super.

F.F.

ganz einfache Antwort: Ja - Das hört sich zwar anfänglich recht komplex an (ist es auch) aber der Sinn eines ORM bzw. OPF liegt genau darin dieses Mapping Klasse - Datensatz zu vereinfachen (ganz einfach gesprochen). Wenn das System wirklich gut ist, definierst Du nur eine KLasse, sagst ggf. in welcher Tabelle(n) der Inhalt gespeichert werden soll und der Rest (incl. Anpassung der Datenbank beim Kunden) macht das darunterliegende System. Um einen Datensatz zu laden reicht dann z.B. ein

Delphi-Quellcode:

 var Kunde: TKunde;
begin
  Kunde := TKunde.create(1);
...
end;

wobei 1 die ID des Datensatzes ist. Die Abfrage der Daten in der Datenbank und die Zuordnung zur Klasse geschieht dann in 2-3 Methoden die für alle Klassen funktionieren - die müssen also nicht immer für jede neue Klasse individuell geschrieben werden.


Grüße

[Jumpy]

Vielleicht nur zuviel reininterpretiert, aber imho geht die ursprüngliche Frage aber auch noch weiter.

Zitat:

Bisher habe ich: Komponenten drauf, paar Zeilen Code - fertig. Nix Klassen usw.

Da geht's find ich nicht nur um OOP vs. Prozedurale Progrmmierung, sondern auch um Trennung der Anwendungslogik von der Darstellung usw. bis in Richtung der ganzen Pattern-Geschichten.

Und vielleicht auch RAD vs. "vernünftiger Struktur"?

Mich interessiert dieser Gedanke nämlich auch, da ich mitlerweile auch versuche Logik und GUI zu trennen, ich aber oft auch nur so kleine Mini-Programme auf die schnelle machen muss, wo irgendwer sich ein paar Daten aus der DB mit anzeigen lassen muss um dann ggf. diese zu Filtern und als CSV zu exportieren und das war's dann schon.
Und da mach ich's dann auch wie der TE. Paar VCL-Komponenten drauf und fertige VCL-Objecte wie TStringlist verwendet und fertig, da der Mehraufwand mit Pattern usw. sich da kaum lohnt.

Sprich irgendwo gibt es wahrscheinlich eine Grenze ab wann es sinnvoll wird "vernünftig" zu arbeiten.

[Sir Rufo]

Zitat:

Zitat von fkf (Beitrag 1242965)

Zitat:

Aber auch ein anderer Aspekt hat mich damals wie hier in der Fragestellung beschäftigt: Wenn ich eine relationale Datenbank habe, in meinem Programm aber mit Objekten arbeiten will, muss ich dann tatsächlich ein Objekt definieren und beim Einlesen der Daten, diese in ein Objekt kopieren? Soll man also Klassen für Datensätze definieren? Wenn die Fragestellung hier so gemeint ist, ist sie sicherlich interessant.

Genau das ist meine (ungelöste) Frage, die ich bisher (aus Bequemlichkeit/Unkenntnis) immer mit "Nein" beantwortet habe.
Eine vertiefende Diskussion (inkl. prakt. Vorgehensweise/Beispielen) wäre super.

F.F.

Weil man dabei anders denken muss :)

Erst erstellt man die benötigten Objekte, die für die Problemlösung gebraucht werden
Dann die notwendigen Methoden (Suchen, Laden, etc.)

Dann schafft man sich die Speicherstruktur (z.B. eine Datenbank) die alle diese Anforderungen erfüllen kann

Diese Speicherstruktur kann dann auch nach Belieben geändert werden (Datenbanksystem X, Dateibasiert, Webservice, etc.) solange diese alle Anforderungen erfüllt.

[süden]

Na, da habe ich ja was angestoßen ....

... ich schließe mich meinen Vorrednern an, Ihr habt's alle getroffen, was ich meine.

ORM bzw. OPF ??? Das Rad neu erfinden? Gibts doch schon, welche sind gut?

Ich habe mich schon damit beschäftigt.
In der Fachliteratur wird das alles schön strukturiert und logisch dargestellt.

Aber in Bezug auf Datenbankanwendungen UND Praxis (wenns kein Hobby ist) habe ich nicht viel gefunden.
Datenbank = schon Klassen usw.

Es geht mir darum, es besser und auf Dauer einfacher und sicherer zu machen.
Dabei möchte ich nicht "mit Kanonen auf Spatzen schießen" nur weil es so schön ist, etwas zu können.

Erstmal vielen Dank für das Interesse und die Antworten.
Ich habe erfahren, ICH BIN NICHT ALLEIN, schon mal ein gutes Gefühl.

[MrSpock]

Dann will ich mich auch mal outen, ist ja gerade wieder aktuell :shock:

Ich nutze für das Einlesen von Daten aus Datenbanken für die einzelnen daten nicht selbst erzeugte Klassen. Ich nutze FibPlus als Komponenten und lesen dann Daten ein, die in DBGrids oder anders dargestellt werden. Das modifizieren von Daten geht dann ggf. über diese Komponenten oder auch mal über Methoden, die aber dann nicht dem Datenobjekt zugeordnet sind. Was ich damit meine will ich an einem kleinen Beispiel erklären. Angenimmen ich habe ien Bestellung mit Positionen. Dann habe ich all diese Daten in einer Datenbank. Es gibt aber in meinem Programm kein Objekt AktuelleBestellung, die die Daten enthält. Ich erzeuge dann eine Rechnung, auch dazu gibt es keine Methode in der Form AktuelleBestellung.ErzeugeRechnung, weil es ja das Objekt nicht gibt. In diesem Sinne landen die Daten also in der Regel in meinen Programmen nicht in "zugehörigen" Objekten.

[mkinzler]

Zitat:

ORM bzw. OPF ??? Das Rad neu erfinden? Gibts doch schon, welche sind gut?

(Reihenfolge ohne Wertung)
hcOPF
dORM
mORMot
tiOPF
TMS Aurelius

[stahli]

Zitat:

Zitat von süden (Beitrag 1242927)

ich liebäugel schon lange mit Klassen (nicht lachen bitte), und habe ein schlechtes Gewissen, weil ich noch keine selbst gebaut habe.

Du musst Dich nicht schämen, das ist nix schlimmes, aber Du solltest daran arbeiten... :stupid:

Das Thema interessiert mich auch sehr. Im Grunde geht es um einen Themankomplex:

- Trennung Daten+Geschäftslogik von der GUI
- lose und einfache Verbindung der beiden Schichten
- effektive und einfache Definition der Klassen
- effektive und einfache Einbindung von Datenbanken (ORM)

Ich finde es schade, dass das Thema bisher so vernachlässigt wird.
Es gibt zwar verschiedene Lösungen für einzelne Teilaspekte aber m.E. nichts was alles abdeckt.

Im Grunde geht es daraum:
- Ich will sehr einfach Klassen definieren. Bestenfalls über Metadaten (also Auflistung der gewünschten Probpertys) oder sogar grafisch. Die grundlegenden Eigenschaften und Fähigkeiten sollen automatisch vorhanden sein.
- Ich will den Klassen die Geschäftslogik (Methoden) hinzufügen können.
- Ein Framework soll sich darum kümmern, die Objekte zu erzeugen, zu verwalten und auf Anfrage bereit zu stellen (Kunde(12345)).
- Die Datenspeicherung soll ebenfalls automatisch und möglichst flexibel erfolgen.
- Die GUI soll keinerlei Kenntnis der Daten und Geschäftslogik haben. Sie soll lediglich wissen, welche Daten sie darstellen soll (Namen eines Kunden oder Kennzeichen eines KFZ) und wo sie diese abrufen kann. Die GUI sollte also weitgehend ohne Quelltext auskommen. Wenn ein KFZ-Objekt in seiner Eigenschaft HatTÜV false liefert könnte ein OK-Schalter deaktiviert werden, ohne dass die GUI selbst weiß warum.
Dafür muss die Datenschicht natürlich Schnittstellen bereit stellen, an die die GUI gebunden werden kann.


Grundsätzlich würde ich komßplexere Projekte eher mit Klassen aufbauen, da die Projekte dann aus meiner Sicht flexibler zu warten und besser zu verstehen sind.
Andererseits ist es natürlich auch möglich, die gesamte Funktionalität in Datenbanken zu packen und dann in der GUI nur noch dumme DB-Controls zu verbauen.
Letztlich ist das Geschmacksache und von den eigenen Fähigkeiten abhängig (bzw. davon was man als Entwickler besser kann).

Wichtig ist auf jeden Fall, die Geschäftslogik nicht in der GUI umzusetzen und beides miteinander zu vermischen. Dann hat man schon mal die besten Voraussetzungen für eine vernünftige Projektstruktur.

Ich würde mir wünschen, dass Delphi diesbezüglich besser unterstützen würde.



Hier mal einige Links, die in diese Bereiche gehen:
http://www.delphipraxis.net/164573-d...nd-hoeher.html
http://www.delphipraxis.net/161102-k...onisieren.html
http://www.delphipraxis.net/172249-d...iskussion.html
http://www.delphipraxis.net/165090-g...nkprojekt.html
http://www.delphipraxis.net/164270-k...zu-mormot.html
http://www.delphipraxis.net/176478-m...realitaet.html

Und natürlich:
[Werbeblock]
http://www.delphipraxis.net/173360-s...framework.html
[/Werbeblock]

[p80286]

Kann sein, daß ich Dich da falsch verstanden habe:

Zitat:

- Die GUI soll keinerlei Kenntnis der Daten und Geschäftslogik haben. Sie soll lediglich wissen, welche Daten sie darstellen soll (Namen eines Kunden oder Kennzeichen eines KFZ) und wo sie diese abrufen kann.

Wenn das (G)UI keine Ahnung von den Daten hat, dann übergibst Du kein KFZ-Kennzeichen, sondern einen 10(?)stelligen alphanumerischen Code.

Übrigens würde ich zumindestens die "Oberflächenlogik" als Teil des UI behandeln. Typische Schreibfehler erkennen, ist oft von der eingesetzten Tastatur(sprache) abhängig. Damit würde ich die "Geschäftslogik" nicht belasten.

Gruß
K-H

[stahli]

Stimmt beides.


1) Binding

Die GUI-Controls sollen m.E. nicht die gesamte Datenschicht und schon gar nichts von der Businesslogik kennen.

Ein Edit soll nur wissen, dass es die Eigenschaft Name eines Objektes mit der ID 12345 darstellen und ggf. ändern soll.
Oder die Eigenschaft Caption des Objektes mit dem Namen "Form1".
Oder die Eigenschaft "Kennzeichen" eines Objektes mit dem Namen KFZ1.

Das Edit muss dann einen Manager beauftragen, das gewünschte Objekt zu finden und muss dann nachsehen, ob dieses die gewünschte Eigenschaft besitzt. Ggf. muss der Wert der Eigenschaft noch in einen anderen Datentyp umgewandelt werden.

Der Manager seinerseits kann nach bestimmten Regeln in der Datenschicht nach dem Objekt suchen oder z.B. auch per FindComponent innerhalb der GUI. Dem Edit ist es somit egal, ob es an die Datenschicht gebunden ist oder an das Formularcaption.

Im Grunde ist es ähnlich wie ein DBEdit an ein Tabellenfeld zu binden - nur eben viel flexibler.

Die GUI-Schicht selbst kennt dabei weder die Datenschicht noch umgekehrt.


2) GUI-Logik

Die GUI darf und muss natürlich selbst auch Logik erhalten aber das sollte sich wirklich konkret NUR auf die sichtbaren Aspekte beziehen.
Ein MaskEdit ist ein schönes Beispiel. Es akzeptiert selbst schon nicht, wenn ungültige Zeichen z.B. für ein Datum eingegeben werden.
Man könnte ähnliche Prüfungen auch im Formular durchführen, solange man dafür keine Analysen in der Datenschicht benötigt.
Wenn ich z.B. die Kinder für Personen erfasse und die Geburtsdaten prüfe (dass die Kinder nicht vor den Eltern geboren sind usw.) dann muss solch eine Prüfung in der Datenschicht erfolgen. Diese könnte eine Schnittstelle TPerson.KinderSindValide unterstützen.
ButtonOk.Enabled könnte an Person("#Aktuell").KinderSindValide gebunden werden. Dann kann ich die Person nur speichern, wenn die Datenschicht das erlaubt, ohne dass die GUI wissen muss worum es geht.

Auf ungültige Zeichen prüfen kann man natürlich auch schon direkt in der GUI, wobei ich mich frage, ob das immer Vorteile bringt.

[p80286]

Zitat:

Zitat von stahli (Beitrag 1243037)

Wenn ich z.B. die Kinder für Personen erfasse und die Geburtsdaten prüfe (dass die Kinder nicht vor den Eltern geboren sind usw.) dann muss solch eine Prüfung in der Datenschicht erfolgen. Diese könnte eine Schnittstelle TPerson.KinderSindValide unterstützen.

Interessantes Beispiel.
Wie ist der Ablauf?

• Abruf des Elterndatensatzes
• Zuweisung der Info "hatKind(er)"
• Erfassung der Kinderinformation u.u. mit angepasster Oberfläche

oder vllt. so

• Erfassung der Personendaten
• Suche der Eltern
• Zuweisung der Info "ist Kind"+ID_Eltern)

Wobei meiner Meinung nach die erste Möglichkeit Benutzerorientiert und die zweite Datenbankorientiert ist. Optimal wäre es den Ersten Ablauf zu zeigen und den zweiten in der "Datenwirklichkeit" zu tun.
Und so etwas kannst Du nur erreichen wenn das UI nicht mit der Datenschicht fix verdrahtet ist.

Zitat:

Auf ungültige Zeichen prüfen kann man natürlich auch schon direkt in der GUI, wobei ich mich frage, ob das immer Vorteile bringt

Wie üblich, es kommt darauf an, ist ja hier oft genug diskutiert worden (copy und paste ....)

Gruß
K-H

[stahli]

Welcher Weg für das Eltern-Kinder-Beispiel der beste ist muss man im Projektkontext sehen.

Wenn Eltern und Kinder von der selben Klasse TPerson sind ist das schon etwas anderes als wenn man einer Person eine Liste von Autos zuordnet.

Das ist der Knackpunkt:

Zitat:

Und so etwas kannst Du nur erreichen wenn das UI nicht mit der Datenschicht fix verdrahtet ist.

Unter dieser Voraussetzung hat man im Grunde alle Freiheiten.

In der Datenschicht kann ich meine Personen definieren, die eine Liste von anderen Personen erhalten kann (die Kinder) und eine Liste von Autos.

Optimal wäre es, wenn ich für jede Klasse ein "Bearbeitungsfoirmular zuweise", das projektweit gilt. Wenn ich irgendwo eine Person sehe kann ich das zugewiesene Bearbeitungsformular TFormPerson durch Doppelklick erzeugen und öffnen. Ebenso ein Formular für Auto-Objekte.

Die GUI-Controls werden automatisch an die passenden Objekteigenschaften gebunden, ohne dass man dazu etwas programmieren muss.

Der OKButton.Enabled wird an das FormarObjekt.IsValide im Personenformular oder FormularObjekt.IsValide im Autoformular gebunden. "FormularObjekt" ist das Objekt, für das das Formular geöffnet wurde. Das alles kann ohne Quelltext realisiert werden.

Ob man nun die Kinder in einer Tabelle erfasst oder in einer Listbox sammelt und jeweils wieder über ein eigenes Formular bearbeiten lässt, ist dann eigentlich zweitrangig.


Ein Problem, das ich in meinem Framework auch noch nicht bearbeitet habe ist das Verwerfen von Änderungen.
Wenn ich z.B. ein Kind hinzufüge muss das Kind-Objekt in der Datenschicht erzeugt werden. Wenn ich das Bearbeitungsformular aber schließen und das Kind verwefen will oder muss, muss das Objekt aus der Datenschicht auch wieder entfernt werden.
Gleiches gilt, wenn ich den Namen einer Person ändere und die Änderung wieder verwerfen will (ESC). Es muss dafür so eine Art Transaktion geben, die es ermöglicht, Objekte und Objekteigenschaften vorläufig zu ändern und später die Änderung fest zu machen oder zu verwerfen.

Diese Transaktionsverwaltung sollte nicht einer Datenbank überlassen werden da (zumindest in meinem Framework) die Objekte ja auch ohne Datenbankanbindung erzeugt und persistiert werden können.


Den beste Lösung für das Eltern-Kind-Beispiel müsste man sich noch überlegen. Man sollte sich daran orientieren, was der Anwender am ehesten wünscht.
Egal, ob man die Kinder in einer Tabelle oder in einer Listbox erfassen lässt, die Objekteigenschaften und die Validitätsprüfungen wären jeweis die gleichen.
Im Falle eines Kinder-Bearbeitungsformulars würde der OK-Button im Fehlerfall deaktiviert und ich könnte das Kind nicht schließen, im Falle einer Kinder-Tabelle wäre der entsprechende Datensatz rot markiert und ich könnte meine Person nicht schließen.


Wichtig ist vor allem, dass man im Formular nichts prüft was die Daten betrifft. Solche Zugriffe sollten immer auf definierte Schnittstellen begrenzt und darüber hinaus abstrahiert werden.

Das Formuar sollte auch auf keinen Fall die Klassen TPerson und TAuto kennen. Damit wäre eine lose Bindung schon dahin.


Man könnte die Datenschicht eigentlich fast als Komponente betrachten.
Das Projekt nutzt z.B. eine TEdit anhand derer Schnittstellen, ohne sich über dessen Innenleben Gedanken zu machen.
Das Projekt setzt die Eigenschaft Text eines Edit und liest sie wieder aus. Es kann prüfen, ob das Edit sichtbar und aktiviert ist oder ob es den Fokus hat.
Genau so kann und sollte die Datenschicht betrachtet werden. Es gibt Schnittstellen, an die sich die GUI binden kann - alles andere ist Privatsache. Natürlich ist die Zugriffsmöglichkeit auf die einzelnen Detaildaten komplexer als auf einfache Propertys einer Komponente, weshalb ein Manager für die Vermittlung zwischen GUI und Datenschicht erforderlich ist. Der kennt einige Schnittstellen der GUI (und kann dort über Datenänderungen informieren) und kennt die Struktur der Datenschicht (und kann so die benötigten Objekte verwalten und heraus geben). Die Objekte selbst kennen auch wiederum den Manager und können dort z.B. den Besitzer eines bestimmten Autos erfragen - genau wie die GUI.


Seit der erweiterten RTTI von D2010 lassen sich solche Dinge wunderbar umsetzen (schaffe ich ja sogar :stupid:).
M.E. ist das ein völlig neues Arbeiten. :love:


Früher gab es mal ECO und Bold wo m.E. ähnliches versucht wurde. Das wurde dann aber leider nicht richtig ausgebaut.

[vagtler]

Zitat:

Zitat von stahli (Beitrag 1243060)

[...] Früher gab es mal ECO und Bold wo m.E. ähnliches versucht wurde. Das wurde dann aber leider nicht richtig ausgebaut.

Leicht OT: An ECO wird wohl noch immer mehr oder weniger aktiv gearbeitet: http://www.new.capableobjects.com/downloads/ - allerdings als reines .NET-Framework.

[Furtbichler]

Lustig: Das aktuelle Projekt arbeitet nur mit Views zur Ansicht und Operationen zur Manipulation der Objekte. Die ursprünglichen Programmierer haben doch tatsächlich ein eigenes ORM geschrieben (in C#), weil sie wohl meinten, sie seien die Größten. Nun denn.

Daten werden so gut wie nie direkt verändert, sonder immer über stored procedures. Also ist der Sinn eines ORM nur der, viel Code zu produzieren.

Was benötigen wir hier also? Na ja, eigentlich nur etwas zum Binden der Daten an visuelle Darstellung, und da täte es auch einfach nur ein TDataSource. Die Operationen selber werden dann mit Businessoperationsbjekten umgesetzt, die kann man Testen und fertig. Die einzelnen Formulare, die die BO darstellen, haben dann natürlich ein Viewmodel. So kann man BO und VM wunderbar testen.

Es muß nicht immer ORM sein, es kommt *immer* auf die Problemstellung an. Im aktuellen Fall ist die Businesslogik in den Stored Procedures untergebracht. Muss man nicht machen, kann man aber. Ergo ist ein ORM überflüssig.

Wenn aber nicht, wenn also die ganze Logik in der Anwendung abgebildet wird, dann geht es ohne ordentliches ORM nicht.

[süden]

Hallo,

danke für die rege Anteilname, aber ...
... die letzten Einträge haben wenig mit meiner (Anfänger)Frage zu tun.

Vielleicht wäre es das Thema wert, für die Profis ein eigenens Thema aufzumachen? Dort könnten dann die konreten Details besprochen werden.
Ich könnte dann mitlesen.

Mein Wunsch wäre hier eine Grundsatzdiskussion. Zur allgemeinen Vorgehensweise, wie ein Projekt aufgebaut werden sollte.
Mit Tipps zu funktionierenden Dingen.

Oder Ihr macht weiter und ich mache einen Neuen auf.

Nichts für Ungut ...

[süden]

PS: Ich bin nicht beleidigt, ich fühle mich nur ausgegrenzt und überfordert.

[Sir Rufo]

Zitat:

Zitat von süden (Beitrag 1243258)

PS: Ich bin nicht beleidigt, ich fühle mich nur ausgegrenzt und überfordert.

Das geht allen so, die vier Räder an eine Platte schrauben und das Teil sich bewegt, und dann fragen, wie man jetzt einen konkurrenzfägen Formel-1 Rennwagen baut.

Soll heißen, es ist nicht trivial

[stahli]

Ich kann Deine Überforderung durchaus verstehen.
Deshalb finde ich es ja schade, dass Delphi noch keinen Königsweg für eine andere Art des Arbeitens mit liefert.

Dieser "Königsweg" würde wiederum mehrere Bereiche umfassen, die zusammenspielen müssen um ein einfaches, übersichtliches und flexibles Gesamtkonzept zu erhalten.

Insgesamt ist das schon recht aufwendig und es gibt unterschiedliche Lösungsansätze.
Schön wäre es, wenn es ein fertiges Gesamtpaket mit Demoprojekten gäbe, so dass die Programmierer einen schnellen Zugang finden.

Leider ist das noch nicht gegeben und die Diskussionen sind eher theoretischer Natur bzw. beziehen sich auf unterschiedliche Teilaspekte des Ganzen.


Das Problem hast Du ja in Deinem Eröffnungsbeitrag angesprochen.
Für deren Lösung gibt es unterschiedliche Ansätze. Der eine schwört auf dieses der andere auf jenes.

Der einheitliche Tenor aller Lösungen sollte sein: Trennung von GUI und Businesslogik+Daten.
In einer OnClick-Behandlung sollte man also NIEMALS etwas berechnen oder ändern, das die Projektdaten betrifft (egal ob diese in einer Datenbank oder in Objekten verwaltet werden). Insofern verführt Delphi sehr dazu, ungünstig zu programmieren.
Zum Lernen und für kleine Demoprojekte ist das zwar in Ordnung und bequem, aber wenn Projekte wachsen wird es schnell sehr unübersichtlich und fehleranfällig.

GUI und BL zu trennen macht etwas mehr Aufwand (wenn man kein Framework nutzt das diesen Aufwand wieder minimiert), ist aber langfristig gesehen für größere und wichtige Projekte der bessere Weg.

Versuche einfach mal, auf direkte Datenzugriffe aus dem Formularquelltext zu verzichten. Der Aha-Effekt wird sich sicher einstellen.


Was insgesamt der beste Weg dafür ist musst Du selbst heraus finden. Einen Königsweg gibt es eben leider (noch?) nicht.

[Hansa]

Zitat:

Zitat von süden (Beitrag 1243258)

ich fühle mich nur ausgegrenzt und überfordert.

Kann ich verstehen, allerdings ausgegrenzt, das stimmt jetzt wirklich nicht. Die "Experten" schiessen aber wirklich öfters weit über das Ziel hinaus. Du weisst, was ein Record ist ? Ja, das sind eben Daten, die irgendwo gespeichert werden. Wenn ich jetzt noch da in der Logik die Behandlungsweise dieser Daten reinpacke, dann ist das ein Objekt/Klasse.

Ne, das wird wieder zu theoretisch. Am besten ist immer noch das TP 5.5 Handbuch. Das stammt zwar aus ca. 1990, aber weil keiner damals wusste, was OOP eigentlich ist oder wozu das gut ist, ist es einfach gehalten.

http://edn.embarcadero.com/article/i..._OOP_Guide.pdf

[süden]

Danke, Ihr seit so lieb - ich bin wieder dabei.

Bisher habe ich genau das gemacht: Klick -> a + b = c ....
und es hat funktinoniert (!?)

Das Ding ist gewachsen und Anwender melden sich, könnte man ...
... klar, warum nicht ...
und dann häng ich da, bekomme meinen Code nicht mehr gebacken + 10-20 mal so viel Zeit wie geplant (und bezahlt) ... Ihr kennt das sicher.

1) Also - Klassendesign lernen
2) Keine BL im Form
3) Date trennen? Wie? die kommen ja im Form an !!! Und es ist so einfach die da zu lassen!

[Hansa]

Zitat:

Zitat von süden (Beitrag 1243294)

3) Date trennen? Wie? die kommen ja im Form an !!!

Welches Date ? Das ist kein deutsches Wort und auf englisch ist 'Date' in Deutsch ein Datum (=Tages-Zeitraum), aber es kann auch die Einzahl von Daten sein. :shock: . Wer soll denn das und noch mit nicht mal richtigem Denglisch noch beantworten ? Ich sage nur : Kauderwelsch.:mrgreen:

[süden]

Tschuldigung, ich wollte DATEN schreiben. Nicht Date = Datum.

[Hansa]

Du kannst also doch Deutsch ? :P Für Rest gilt : TP 5.5

[stahli]

So pauschal kann man schlecht sagen, was die beste Herangehensweise ist.

Es ist auch davon abhängig, die Dein bisheriges Projekt aufgebaut ist (eine Datenbank und welche - welche Datenbankkomponenten (DBEdit?)), wie die Daten bisher im Formular eingebunden werden, wie Berechnungen usw erfolgen.

Grundsätzlich könnte man sagen, dass die gesamte BL ohne ein Formular funktionieren sollte.
Dann könnte man sagen: BL.BerechneAlleKundenAlter oder BL.SucheAlleKundenMit('A') oder BL.Kunde(1).AddiereZuKonto(1000).

Vom Formular aus ruft man dann nur noch die definierten Schnittstellen auf.
Das Formular muss die Klasse TKunde und TKonto dann nicht kennen. Es muss nur wissen, wo es die Daten zur Darstellung her bekommt, aber nichts von Berechnungsformeln usw.

"BL" könnte eine Klasse sein, oder ein eigenes Projekt in einer Projektgruppe oder einfach ein DataModule (wobei das dann keine richtige Trennung von der GUI mehr ist) oder sogar eine DLL.

Die Frage ist dann wieder, wie man der GUI beibringt, welche Daten sie anzeigen soll.
Das sollte möglichst einfach und flexibel sein und genau klemmt derzeit noch die Delphi-Säge.

[Furtbichler]

Zitat:

Zitat von stahli (Beitrag 1243307)

"BL" könnte eine Klasse sein, oder ein eigenes Projekt in einer Projektgruppe oder einfach ein DataModule (wobei das dann keine richtige Trennung von der GUI mehr ist) oder sogar eine DLL.

Der Business-Layer ist idealerweise eigentlich keine Klasse, sondern eine Schicht: Wenn Du alle Klassen deines Projekts vertikal so anordnest, das die Abhängigkeiten einer Klasse ('Uses Liste') immer nur nach oben zeigen, dann kannst Du diese Hierarchie in einzelne Schichten unterteilen.

Ganz oben ist die UI, also Formulare, Komponenten usw.

Ganz unten die Datenmodule (wenn Du welche hast). Oberhalb der Datenzugriffschicht (also dort, wo mit der Datenbank kommuniziert wird) liegt normalerweise der Business Layer, der Daten von der Datenschicht nimmt, Umformungen der Daten vornimmt (nach Aufforderung von oben) und diese wieder an die Datenschicht zum speichern übergibt.

Die Befehle zur Datenmanipulation kommen aus der UI oder besser noch: Aus einer Schicht dazwischen, dem Viewmodel. Dieses Viewmodel stellt eine 'Fassade' dar (nicht mit dem Pattern gleichen Namens verwechseln), welche die Daten und Operationen der BL-Schicht so maskiert, das die UI diese ohne großartige eigene Logik darstellen kann.

Die Sache mit dem Viewmodel ist nicht sehr weit verbreitet und bei kleineren Projekten auch nicht wirklich nötig, denn es ist schon eine ganze Menge Mehrarbeit.

[stahli]

Genau diese Komplexität ist der Grund, warum ich ein entsprechendes RundumSorglosPaket im Delphi vermisse.

Die meisten Programmierer hätten doch sicher gern ein Framework, das einem die entsprechenden notwenigen Arbeitsschritte abnimmt ohne dass man sich mit den Details herumschlagen muss. (Ich zumindest auf jeden Fall.)

Es ist doch ineffektiv, wenn jeder sein Framework selbst erfindet... Und Anfänger würden direkt zu einem guten Projektaufbau hin geführt.

[Hansa]

Tja, @sueden : siehst ja selber, dass Einführung in OOP so nicht geht. 8-)

[stahli]

Man redet über Anwesende ja nicht in der dritten Person ;-)
aber ich denke, süden versteht schon die OOP an sich - das Problem ist wohl eher die Stufe drüber, also die Strukturierung der Projektebenen und deren Verbindung.

[Hansa]

Welche dritte Person ? :shock: Ich rate auch Dir oder Furtbichler : Handbuch für TB 5.5 OOP. Da steht alles drin, was wichtig ist. Da wird nämlich einiges viel zu kompliziert angegangen.