Mehrere Schichten Programmieren

KlausB

Hallo

eine Menge Zeit

Welcher Kunde gibt dir eine Menge Zeit.
Meist ist es doch so
- verschiedene Angebote
- der billigste bekommt den Auftrag (leider)

Deinem Auftraggeber ist es (gelinde gesprochen) schwi.... egal
ob dein Programm schoen OO ist oder nicht
wenn dieser OO-Programm das 2-3 fache kostet

Ich habe selbst sowas schoen sehr oft erlebt und kann nur sagen
wenn man nur fuer sich Programmietr ist OO echt gut oder
wenn der Kunde bereit ist mehr Geld wie bei anderen hinzulegen auch
aber sonst - der Preos macht es - und sonst nichts

Wenn man dagegen nur fuer sich Programmiert ist es richtig

MfG
Klaus

akari

Hallo

tja, das mit der benötigten Zeit ist wohl das Hauptproblem.
Zum Glück habe ich einen Chef, der mit meinem Vorgehen einverstanden ist und das gegenüber den Kunden auch durchsetzt.
Dabei hilft natürluch der Umstand, das wir mehrere Projekte derselben Art (komplexe Datenbank) haben (werden), und deshalb eine solche zwar einmalig aufwendige, aber dafür wiederverwendbare Arbeit sich lohnt. Für einen Auftrag ist es Overkill, da hast du recht.

bis bald
akari

dschensky

Mr12,

Mr12 schrieb:

...wie soll ich die datensätze an die Gui weitergeben. ...

z.B. so - (ungetestet :))

DbLayer db = new DbLayer("MyRealDatabase");    //DB-Schicht erzeugen
Kunde k = new Kunde();    //Fachklassen-Instanz anlegen
db.GetKunde(k, 42);    //Kunde-Objekt mit bestimmtem primary key aus DB holen
TKundeForm f = new TKundeForm(this, db, k);    //GUI für Kunden erzeugen
f.ShowModal();    //Ansichts-/Bearbeitungs-Modus für Kunden starten
...
TKundeForm::Save()
{    //wird bei Klick auf Save-Button aufgerufen
    db->SaveKunde(k);
}

KlausB schrieb:

der Preos macht es - und sonst nichts

Meiner Erfahrung nach, kommen noch zwei weitere Punkte hinzu:

Die Anwendung muß "cool" aussehen. Ich wollte es anfangs gar nicht glauben, aber das spielt für viele eine große Rolle. Wenn der erste Eindruck ist: "Oh mann, das Programm sieht total altbacken aus!" habe ich genauso verloren, wie bei "Ach Du Scheiße, wer soll den das bezahlen!?". Und ich meine nicht nur Klicki-Bunti-Programme, wo der Teenager jeden Tag einen neuen Skin ausprobieren will, sondern auch dröge Büro-Anwendungen.
Das Programm muß einfach zu bedienen sein. Das heißt nicht, das es schlicht aussehen soll (siehe 1), sondern daß es möglichst intuitiv zu verstehen sein muß und das der Nutzer vom GUI unterstützt wird - etwa bei der Eingabe von Daten.
Mein Chef hat bei einer Messe potentielle Käufer angelockt, weil in seinem Hauptfenster ein riesiger Button mit der (ebenfalls riesigen) Aufschrift "Kunden" zu sehen ist - bescheuert, aber die Realität.
Überall wird gespart. Und wenn ein Unternehmer statt einer hoch qualifizierten Arbeitskraft eine schlechter bezahlte einstellen kann, weil es die Software ermöglicht, wird er sich für diese Software entscheiden - eine moralische Zwickmühle für Software-Entwickler?

Beide Punkte, um mal wieder auf das Wesentliche zurückzukommen, lassen sich mit OOP imho einfacher realisieren. Insofern spart man letztlich vielleicht sogar Zeit. Das Problem ist bloß, wie man den Kunden davon überzeugt.

junix

dschensky schrieb:

[...] Über das Fernziel kannst Du etwas von dem offiziellen MVC-Jünger Junix in Erfahrung bringen.

Ob ich diesen Titel als positiv oder negativ bewerten sollte? *grübel* (o;

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß und damit auch der Chef des Entwicklers, wenn er erfährt, daß das Projekt 4 Monate später fertig wird u.s.w. ...

Den hier versteh ich nicht... sprechen wir vom selben MVC?

-junix

junix

Ahja und @Mr12: wenn du in Richtung MVC gehst, dann sollte das doch eigentlich klar sein? Ich erstelle man ein grobes Objektmodell auf die Schnelle auf Basis von MVC:

|   Datenbankserver   |
|                     |
+---------------------+
            ^
            |
+---------------------+
|  Database Connector |
+---------------------+
            ^
            |
+---------------------+    +-------------+ 
|    Dein Dokument    |<-->| Deine Views |
+---------------------+    +-------------+
            ^                      ^
            |                      |
+----------------------------------------+
| Deine Datenbankapplikation             |
+----------------------------------------+

Folgende Erklärung:
Dein Dokument besitzt einen "Databaseconnector" und lädt über diesen von der Datenbank alle für sich nötigen Daten runter.
Das view holt sich die Daten (vorzugsweise Call by reference) aus dem Dokument und bearbeitet sie so das es sie anzeigen kann.

dschensky

junix,

junix schrieb:

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß und damit auch der Chef des Entwicklers, wenn er erfährt, daß das Projekt 4 Monate später fertig wird u.s.w. ...

Den hier versteh ich nicht... sprechen wir vom selben MVC?

wenn ich mal zitieren darf:
"In einem Satz ausgedrückt, bedeutet Document/View die Trennung von Datenspeicher- und Anzeigeobjekten."

Alexander Kempf

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß und damit auch der Chef des Entwicklers, wenn er erfährt, daß das Projekt 4 Monate später fertig wird u.s.w. ...

Wo steckt denn Deiner Meinung nach jetzt der Spaghetti-Code - in einer MVC-Implementierung oder in der
Ich-lege-einfach-mal-los-Implementierung?

Wenn ein Programmierer, der von MVC noch nichts gehört hat, derartigen Code betrachtet, wird er sehr
wahrscheinlich nichts verstehen und wirklich länger für Änderungen brauchen. Und eine MVC-Architektur
zu implementieren scheint zunächst auch mehr Zeit zu benötigen (die Übung macht's). Der Vorteil ist,
dass ich mir bei MVC vorher Gedanken über das Programm machen muss. Ich habe schon sehr viel
Code gesehen, bei dem man die Programmiermethode "wildes Rumprobieren bis es klappt" erkennen kann.
Da wird dann an allen möglichen Stellen im Programm ein Refresh aufgerufen und alle Daten neu ein-
gelesen, weil's wegen des schlechten Designs offensichtlich Probleme mit der Aktualisierung gab. Das
passiert meines Erachtens immer dann, wenn man die Logik bröckchenweise über das ganze Programm ver-
teilt und jedes Formular Zugriff auf jedes andere im Projekt hat, alle Variablen sind dann natürlich
mindestens public - besser global. So was zu warten, macht wirklich keinen Spaß. Wenn hier eine tief-
greifende Änderung im Arbeitsablauf vorgenommen werden soll, ist das schon bei einem mittelgroßen
Programm die Hölle.

Ich glaube, dass sich der Aufwand für ein gutes Design lohnt. Und die häufig gebrauchte Ausrede
"Das Programm wird nie erweitert werden" kann ich auch nur schwer gelten lassen - wer das be-
hauptet, spricht sich selbst ja schon hellseherische Fähigkeiten zu.

Gruß,

Alexander

akari

Hallo

Ich glaube, dass sich der Aufwand für ein gutes Design lohnt. Und die häufig gebrauchte Ausrede
"Das Programm wird nie erweitert werden" kann ich auch nur schwer gelten lassen - wer das be-
hauptet, spricht sich selbst ja schon hellseherische Fähigkeiten zu.

Full Ack. Wer einmal etwas für Dritte geschrieben hat, weiß, das sich die Anforderungen bereits im Laufe der Entwicklung (und danach erst recht) ändern. Und
dann sollte man dafür gesorgt haben, das selbst umfangreiche Änderungen nur an einer Stelle durchgeführt werden müßen und keine anderen Abläufe negativ beeinflußen.

bis bald
akari

junix

dschensky schrieb:

junix,

junix schrieb:

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß und damit auch der Chef des Entwicklers, wenn er erfährt, daß das Projekt 4 Monate später fertig wird u.s.w. ...

Den hier versteh ich nicht... sprechen wir vom selben MVC?

wenn ich mal zitieren darf:
"In einem Satz ausgedrückt, bedeutet Document/View die Trennung von Datenspeicher- und Anzeigeobjekten."

Tut mir leid, ich zermartere mir das Hirn und komm nicht drauf was du meinst bzw. hinaus willst....

dschensky

Alexander Kempf schrieb:

Wo steckt denn Deiner Meinung nach jetzt der Spaghetti-Code - in einer MVC-Implementierung oder in der
Ich-lege-einfach-mal-los-Implementierung?

Junix schrieb:

Tut mir leid, ich zermartere mir das Hirn ...

Ups, ich glaube, jetzt verstehe ich die Reaktionen. Die Aussage

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß...

bezog sich (natürlich) auf den Fall, wenn man keine Trennung von Datenhaltungs- und GUI-Code vornimmt.
Ferner ist das eine allgemeine Aussage gewesen, unabhängig davon, wie eng man sich an die MVC-Theorie hält bzw. ob man diese überhaupt benutzt.