Domino 9 und frühere Versionen > ND6: Entwicklung

Größere Notes-Anwendung planen?

<< < (6/7) > >>

Semeaphoros:
Ach, ich hab immer geglaubt, das passiert nur mir .....  ;D

Simon Dotschuweit:
Hi, ich hab mal wieder was ;)

Also, ich versuche gerade meine Dokumenten Klassen in Front- und Backend zu trennen. Ich hab gesehn, das du in der Service App das so machst, das du ein BaseDokument hast und von dem erbt dann SomeDokument und dann gibt es da noch das SomeDokumentUI, welches das SomeDokument integriert.

Jetzt würd ich gerne das Modell um ein BaseDocumentUI ergänzen, in das dann alle z.b. alle UI bezogenen standard events wie querysave implementiert werden können. Aber irgentwie kommen da meine Gehirnwendungen nicht mehr mit, wie wäre denn dann die Beziehung der 4 untereinander?

Weil so wie ich es mir überlegt hab, kanns ned funktionieren(siehe anhang), denn wenn ich bei der SomeDocumentUI das Querysave aufrufe, dann führt es die vom BaseDocumentUI vererbte Methode aus und hat ja keinen zugriff auf das somedoc der SomeDocumentUI.  :-:

Oder wäre es vieleicht sinnvoll, dass ich basdoc und somedoc einen festen varnamen gebe und den Typ auf variant setzte? Weil dann müsste die querysave doch eigentlich auf das aktuelle doc zugreifen und SomeDocumentUI  hätte ja  die doc des BaseDocumentUI mit seinem eigenen überschrieben, right?

Ich hoffe ihr konntet mir folgen und könnt mir mein Kopf etwas entknoten ;)

TMC:
Ich bin kein OO-Spezialist.

Trotzdem eine Frage (nicht nur an Dich):

UIBaseDocument <-> UISomeDocument:

Brauchst Du diese Beziehung überhaupt direkt? Reicht es nicht, über die Backend-Dokumente zu gehen?
Vermutlich macht man doch größtenteils eh fast alles über's Backend?

animate:
Also zuerst melde ich mal Zweifel an den UI-Klassen an. Die Events werden zwar vom UI aus getriggert, ihre Verarbeitung gehört imho aber in die Business Logic, also in deine Dokument-Klasse.

Abgesehen davon: die Beziehung von BaseDocument zu BaseDocumentUI bedeutet, dass das BaseDocument das BaseDocumentUI kennt und umgekehrt. Das Attribut baseDoc in BaseDocumentUI ist also überflüssig.

Die Beziehung übersetzt in Code sieht so aus (Rollennamen nehme ich einfach welche an)

Class BaseDocument
   Private uiDocument As BaseDocumentUI
End Class

Class BaseDocumentUI
   Private document As BaseDocument
End Class


Die Beziehung zwischen den speziellen Klassen würde ich weglassen.
SomeDocument erbt die Beziehung zu einem BaseDocumentUI ja von BaseDocument.
BaseDocumentUI ist ja eine abstrakte Klasse und du kannst dann in der speziellen Klasse festlegen, welche spezielle Implementierung benutzt wird

Class SomeDocument

   Sub init()
      Set uiDocument = new SomeDocumentUI
   End Sub

End Class

Semeaphoros:
Thomas hat das wesentliche schon gesagt, von meiner Seite vielleicht noch eine Ueberlegung in eine etwas andere Richtung.

Vorweg, Simon, ein solches Modell würde sich eventuell anbieten, wenn LS Mehrfachvererbung kennen würde, das ist aber nicht der Fall. Und ist deswegen nicht wirklich wichtig, weil wie Thomas schon gesagt hat, in den UI-Klassen darf keine Logik stecken. Die UI-Klassen sind Interface zwischen Darstellung und Logik und damit in der Regel tendenziell mit "wenig Inhalt". Ich weiss jetzt nicht auswendig, ob das in der Service-App konsequent durchgeführt ist, da haben aber neben mir auch andere Leute noch die Finger drin gehabt.

In einer einer aktuellen Applikation von mir sieht das Modell kurz gefasst etwa so aus:

BaseDocumentClass -- SomeDocumentClass -- SomeDocumentUIClass

im Falle, dass da etwas erweitert werden sollte, könnte es dann so aussehen:

BaseDocumentClass -- SomeDocumentClass -- SomeExtendedDocClass -- SomeExtendedDocUIClass

Alternativ kann man natürlich auch Verbindungen über Attribute machen, so wie es Thomas und auch Notes macht, die zweiwege-Verbindung zwischen Frontend und Backend ist da nicht in jedem Fall notwendig (bei mir aktuell brauch ich sie nicht, was nicht heisst, dass es nicht nützlich sein könnte).

Anders ausgedrückt, das abstrakte BaseUIDoc ist in einem solchen Fall nicht nötig, sämtliche Basislogik, inklusive Event-Handling wie QuerySave steckt in der BaseDocumentClass


Uebrigens, genau diese Ueberlegungen sind ein wesentlicher Bestandteil davon, ob ein OO-Ansatz erfolgreich durchgeführt wird oder nicht.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete