Grosse Programme "übersichtlich" programmieren

[Hansa]

Langsam wirds unübersichtlich, wohl wegen der Patterns. :mrgreen:

'Grosse Programme "übersichtlich" programmieren'

Für mich taucht folgende Frage auf : wer hat in seinen Programmen des öfteren in den Form-Deklarationen folgendes stehen

Delphi-Quellcode:

  TFormXY = class(TForm)

?? Interessiert natürlich nur, sofern das Programm mehr als eine Form hat, was bei größeren Programmen wohl kaum der Fall sein dürfte. Hier hat gerade einer behauptet, das wäre normal. Bin selber aber der Ansicht, dass so etwas Schwachsinn ist. :P

[alzaimar]

Zitat:

Zitat von Viktorii

Zitat:

Zitat von Pfoto

Bezüge auf die GUI gibt es dann nicht mehr, sondern die Klasse gibt
Events ab, auf die ich in der GUI individuell Reagieren kann.

Das würde mich mal genauer interessieren. Könntest du dazu mal ein kurzen Beispielcode posten?

Z.B. TDataSource.OnDataChanged

Zitat:

Zitat von Hansa

Langsam wirds unübersichtlich, wohl wegen der Patterns. :mrgreen:

Nee, eher weil sie nicht eingesetzt werden. Wir haben hier ein Kuddelmuddel aus Meinungen zum Thema oder auch nicht. Ein Entwurfsmuster à la 'Beim Thema Bleiben Oder neuen Thread mit Link aufmachen' würde eine perfekte Übersichtlichkeit herstellen.

Zitat:

Zitat von Hansa

...wer hat in seinen Programmen des öfteren in den Form-Deklarationen folgendes stehen

Delphi-Quellcode:

  TFormXY = class(TForm)

?? Interessiert natürlich nur, sofern das Programm mehr als eine Form hat, was bei größeren Programmen wohl kaum der Fall sein dürfte. Hier hat gerade einer behauptet, das wäre normal. Bin selber aber der Ansicht, dass so etwas Schwachsinn ist. :P

Dein Problem bzw. wieso das Schwachsinn ist, verstehe ich nicht.

[Hansa]

Zitat:

Zitat von alzaimar

Dein Problem bzw. wieso das Schwachsinn ist, verstehe ich nicht.

Eben wegen der "Patterns". :stupid: Aber wieso Problem ? Gut, ich frage anders : wer hat Programmm mit > 5 Forms und da steht überall in den Units :

Delphi-Quellcode:

TFormXY = class(TForm)

Nennt das von mir aus "Meinungsumfrage". :mrgreen:

[Elvis]

Zitat:

Zitat von alzaimar

Einspruch: Das beste Werkzeug verkommt zum Faustkeil, wenn man es nicht richtig anwendet.

Ein Versuch RAD mit vernünftigem Code zu verbinden, war zum Beispiel SWF und WPF in .Net. Aber auch da ist einem der RAD-Teil eher im Weg, und erschwert es zügig eine wartbare anwendung zu bekommen.
RAD im Sinne von Delphis RAD (oder VBs) zielt auf reines Quick & Dirty und du würdest dich wundern wie viele Leute in Delphi 10 Jahre Erfahrung darin haben es falsch zu machen. (btw, JEDER VB'ler hat Jahre Erfahrung darin es furchtbar falsch zu machen)

Zitat:

Zitat von alzaimar

RAD / Delphi bietet uns mit Datenmodulen doch eine Möglichkeit an, um GUI und Logik zu trennen. Datenmodule sind klassisch gesehen doch nur Datencontainer, um sich das ewige hin- und hertransportieren der Daten zu ersparen. Mit der Delphi-Toolleiste können wir derzeit 'nur' Tabellen, Imagelists etc. dort ablegen, um sie im Code gemeinsam zu nutzen. Nichts hindert uns, weitere Funktionen dort zu hinterlegen.

DatenModule sind furchtbare Biester, die Entwicklern vormachen, sie würden ihre App strukturieren, wobei sie in Wirklichkeit worst-case-Pasta erzeugen...
Datenmodule funzen nur, wenn sie globale Variablen sind, und sie benötigen andere globale Variablen um deren Dingsens benutzen zu können.
OTOH, Delphis Designer machen alle Komponenten öffentlich sichtbar, von Kapselung also absolut keine Spur.

Ich muss dir hier also vehement widersprechen: DataModules sorgen für ein schreckliches Applikations design.
MVC, MVP oder irgendeine andere Form von Mediation zwischen Modell, Logik und Darstellung ist damit komplett für'n Arsch.
Alles was ohne Kapselung von außen geändert werden kann, kann dich nicht darüber informieren. Es ist nicht möglich ein elegantes Design mit solchem RADifiziertem Käse zu produzieren, das auch noch team-fähig ist.

Zitat:

@franktron: Genau so. TDataset-Derivate gehören ins Datenmodul und *nicht* auf die Form. Die Logik der berechneten Felder hat doch im Formular nix zu suchen, oder?

Das ist einer der Fehler, die gerne gemacht werden: Datenkrams auf einem DM macht es in keinster Weise besser wartbar als wenn man es gleich auf ein Form klatscht. Ist beides gleich ungeeignet, wenn man wartbare und partitionierbare Anwendungen bauen will.

[Phoenix]

Full Ack. Ich wollte nur nicht dermassen dagegen hauen.
RAD ist ganz sicher das perfekte Werkzeug, um mal kurz einen Prototypen hinzurotzen und um dem Kunden mal schnell was zu zeigen. Wenn man wartbare Anwendungen haben will, sollte man aber in Erwägung ziehen, lieber doch einiges von Hand und dafür richtig zu machen.

Denn sobald man sich ein wenig vom RAD-Weg entfernen muss, weil es eine Anforderung erfordert (und das passiert im echten Leben da draussen häufiger als man denkt), dann muss man sich sonst immer irgendwelche bösen Workarounds ausdenken. Sowas fällt weg, wenn man es gleich 'richtig' macht.

[alzaimar]

Ahoi Elvis,

Wo Du (bedingt) Recht hast (Datenmodule kapseln nichts), hast Du (bedingt) Recht. Natürlich ist das nicht die reine Lehre, aber die öffentlichen Komponenten sollen doch auch öffentlich sein und dienen der Interoperabilität mit den Formularen. Und die Geschäftslogik in Form der Ereignisse ist gekapselt. Der Designer bietet uns leider nicht die Möglichkeit, private Komponenten zu plazieren. Aber wenn das ginge, wäre das natürlich nett.

Das Datenmodule hingegen per se "furchtbare Biester" sind, "die Entwicklern vormachen, sie würden ihre App strukturieren, wobei sie in Wirklichkeit worst-case-Pasta erzeugen", sehe ich nicht. Es gilt immer: Wer's nicht kann, soll die Finger von den 'Biestern' lassen. Man muss sie auch bändigen können...

Bei den Möglichkeiten bzw. den Unmöglichkeiten, mit einer RAD automatisch gute Software zu erstellen, gebe ich Dir aber unbedingt Recht.

Aber wir sprechen von zwei paar Schuhen: Bei Systemen, die die, sagen wir 100.000 Codezeilen-Grenze durchbrechen, wird man sich hüten, mit Klick-und-Gut-Datenmodulen zu arbeiten. Das wäre ja wirklich Selbstmord. Da braucht es dann auch 90% der Komponenten nicht mehr und man sollte Delphi bzw. RAD (=Prototyping) wirklich nur für die GUI verwenden, wobei dann auch die GUI nicht mehr statisch sein dürfte und auch dann Delphi (und jede andere IDE) derzeit nicht in der Lage sein dürfte, die dynamischen Formulare zu unterstützen.

Bei Projekten zwischen 5.000 und 100.000 (nur Hausnummern) bietet RAD eine wirklich brauchbare Möglichkeit, Projekte in vertretbarer Zeit zu vernünftigen Preisen anzubieten, die dann (entsprechende Dispziplin vorausgesetzt) auch wartbar sind. Alles, was darüber hinaus geht, geht damit nicht mehr.

Bevor ich diesen Exkurs abschließe, möchte ich noch darauf hinweisen, das RAD imho eher RAP heißen sollte, also nicht Rapid Application Development, sondern einfach Rapid Prototyping. Und dann verbietet es sich ja, sich eine ordendliche Anwendung zusammen zu klicken...

[franktron]

So jetzt bin ich ganz durcheinander.

Wie macht man denn das heutzutage,
Wenn man mal ganz einfach ein ganz einfache Kundenverwaltungen machen will.

Also Grid für die Liste Neu Anlegen und Edit , Löschen u.s.w. ????

Wie sieht sowas den aus

[Elvis]

Zitat:

Zitat von franktron

So jetzt bin ich ganz durcheinander.
Wie macht man denn das heutzutage,
Wenn man mal ganz einfach ein ganz einfache Kundenverwaltungen machen will.

Die Frage ist immer, was ist einfach und vor allem: Ist es eine reine monolithische App, oder kann es sein, das sie sich zukünftig in ein bestehendes System integrieren müsste.
Natürlich kann es auch sein, dass es von verschiedenen Kunden verschiedene Anforderungen für Integrationen in ihre Systeme gibt.
Alles bis auf 1 ließe sich durch WebServices lösen, bei dem dein Client, also das hier:

Zitat:

Also Grid für die Liste Neu Anlegen und Edit , Löschen u.s.w. ????

Nur ein "Default client" wäre.
Der Kunde könnte den Webservice auch von innerhalb seiner in-House-Systeme aufrufen.
Entweder nur die Logik in einem Server, oder als mash-up im Client.

Software ist schon lange nicht mehr das, was sie mal war. Aber diese ganzen RADifizierten Apps sind komplett ungeeignet um ihre Logik und Prozesse in einem größeren System verwenden zu können.
"Größe" wäre hier nur die Anzahl an unterschiedlichen Diensten, nicht unbedingt die Anzahl der user. Auch kleine Firmen würden sowas bevorzugen, wenn es ihnen uralte Client/Server Apps nicht so schwer machen würden... ;-)


Und ganz btw: Eine Kundenverwaltung wäre auf jeden Fall etwas, dass ich in meine Prozesse integrieren können will. Und damit meine ich keine SOP á la "proprietären ERP client öffnen, xyz machen, Daten exportieren und per Hand in System Z einpflegen"

[grenzgaenger]

@phoenix: letzter post tja, ganz so ist es ja doch nicht. die regions stellen IMHO eine ganz brauchbare möglichkeit dar, um in den sourcecode (eine unit) ordnung zu bringen. wenn es über mehrere units geht, da müssen dann auch andere techniken her.

die DM's wurden ja damals von borland entwickelt, um den ruf der entwickler nachzukommen, die datenzugriffsroutinen zu zentralisieren. das geht ja damit auch... obgleich man die objekt ablage normal nicht braucht, wenn man das system nicht als drag-and-drop system sieht... sondern wenn man es ordentlich macht. und da brauchts das auch nicht mehr, da man die datenzugriffe auch wunderbar in eine eigene unit (oder auch mehrere) verpacken kann ... ich find es noch recht komfortabel, wenn alle tabellenhandlings in einer datei sind... da muss man nicht erst nach den ganzen units/formularen suchen... wo man jetzt ggf. noch 'n feld ändern muss oder noch irgendwelche persistenten felder...

@alzaimar: tja, prototyping, ist auch nicht so straight, da gibts ja auch unterschiedliche Philosophien... vom wegwerfen (von dir erwähnt) bis hin zum weiterentwickeln und zur marktreife zu bringen. wobei ich deinen ansatz (wegwerfen des prototypes) vorbehaltlos unterstütze... diese sind IMHO nur dafür da um designfragen mit dem kunden etwas realitätsnaher abzuklären... dafür taugt es, aber für mehr nicht.

nun noch 'n schönen abend
GG

[alzaimar]

Für eine Desktop-Datenbankanwendung ist das Model "Projekt = Datenmodul + Formulare" doch nun wirklich brauchbar.

Im C/S (Web)-Umfeld kommt man damit wirklich nicht weit, obwohl ich ein System basierend auf TSocketConnection seit 10 Jahren problemlos in einem 24/7-Umfeld und hunderten Erweiterungen in drei Fabriken im Einsatz habe. Aber man kann ja auch mit einem Faustkeil einen Baum fällen.

Ich wiederhole mich: Für kleine bis mittlere Anwendungen (einige wenige Mannmonate) reicht das o.g. Konzept (Datemodul+Formular) und RAD wirklich.
franktron,
Du kannst das System nun so konzipieren, das es auch für zukünftige Erweiterungen gerüstet ist. Dann solltest Du die Finger vom RAD-Ansatz lassen und gleich ordendliche Kunden-Klassen modellieren.

Oder Du willst jetzt eine Lösung, dann nimm ein Datenmodul, einige Formulare (Tipp: TDatasource auf die Formulare, denn vielleicht benötigst Du die Aktion 'Anwender wechselt im Grid den Datensatz') und datensensitive Komponenten (TDBEdit, TDBGrid) etc. Fertig.

Entwerfe die Dialoge so, das sie übersichtlich und intuitiv zu bedienen sind und vermeide Schnickschnack (Skins, coole Buttons etc.). Schließlich baust Du eine Kundenverwaltung und keinen Podcastplayer.