Domino 9 und frühere Versionen > ND6: Entwicklung

Größere Notes-Anwendung planen?

<< < (3/7) > >>

Semeaphoros:
Dem von Thomas gesagtem ist nur wenig hinzuzufügen. Für jedes Feld eine eigene Setter oder Getter Methode zu machen, halte ich für sinnlos. Die Feldnamen als Konstanten in ein eigenes Modul zu hinterlegen ist ein sehr guter Vorschlag und kann gleichzeitig auch als Bestandteil der Doku dienen.

Marinero Atlántico:
Um Himmels willen nein. Ich würd das auch nicht in der Designphase in das Diagramm packen.
Solche Variablen ändern sich schnell mal, stärker zu Beginn des Projekts.
Wenn du die getter und setter ins Diagramm schreibst, mußt du an 6 Stellen ändern:
Property in Code, setter in Code, getter in code, Property in Modell, setter in Modell, getter in Modell.
Am Rande: In Eclipse drücke ich einmal das Renaming Refactoring und Eclipse kümmter sich um das umbenennen der getter/setter, sowie aller existierenden Referenzen.

Die zusätzliche Information, die die explizit vorhandenen getter und setter liefern, tendiert gegen Null und es macht das Modell unübersichtlicher. Selbst wenn - was selten der Fall ist - der getter oder setter nicht einfach gettet oder settet sondern vor- oder nachbearbeitet, gehört diese Information allenfalls als Kommentar zu der Variable und nicht als expliziten getter oder setter im Modell.

Axel

Simon Dotschuweit:
@Semeaphoros:

Ich bin gerade deine beiden Beispiele(Adressbuch und ServiceDB) am studieren und bin nicht ganz sicher, welche ich als Vorlage für mein Design verwenden soll. Bitte versteh mich jetzt nicht falsch,
ich will deinen Quellcode nicht kopieren, will mich aber an deinem Ansatz orientieren, da ich zwar viel
Erfahrung in OO, aber nicht in Notes habe. Wenn ich das richtig sehe, dann hast du beim Adressbuch
auf N zu N Relationen gesetzt und bei der ServiceDB auf Main-Responsedocs.

Für meinen Ansatz müsste ich beides kombinieren, ich brauch also beide Relationen, irgentwie hab ich aber den Eindruck bekommen, dass z.B. das BaseDocument beim Adressbuch ausgereifter ist (z.B. die Absicherung gegen Replikationskonflikte über eigene Docids), oder enthält es einfach nur mehr Funktionalität für die N-N Relationen? Lässt sich eine Kombination überhaupt ohne weiteres umsetzen? Oder beissen sich da bestimmte Funktionalitäten?

Thx

Semeaphoros:
Das hast Du richtig beobachtet ....  :D

Wenn Du N zu N Relationen brauchts, orientiere Dich an der AdressDB. Deren Architektur hat zwar einen älteren Ansatz, ist in manchen Teilen technisch weniger ausgereift als die Service-Applikation, daran wurde aber auch wesentlich länger gearbeitet, ist also - wie Du richtig bemerkts - ausgereifter. Kombinieren könnte man die Ansätze eigentlich schon, macht aber irgendwie keinen Sinn, denn wenn man 1 zu N und N zu N braucht, dann ist 1 zu N eine Untermenge von N zu N. Was ich allerdings heute anders machen würde, das wäre eine Trennung von UI und Backendklassen, das ist bei der gegenwärtigen Lösung nicht gegeben.

Simon Dotschuweit:
Ok, dass heißt also wenn ich 1 zu N und N zu N Relationen brauche, macht es Sinn, sich an der AdressDB zu orientieren und für die 1 zu N auf die Responsearchitektur zu verzichten. Denn mir ist ein durchgehender Ansatz sowieso lieber. (Außer dem ist die AdressDB besser dokumentiert  :D)

Für die Unterteilung nach Front und Backend schiel ich dann mal ab und zu auf die ServiceDB, da werd ich dich auch bestimmt noch viel fragen ;)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete