Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: Simon Dotschuweit am 20.06.05 - 18:40:35
Titel: Größere Notes-Anwendung planen?
Beitrag von: Simon Dotschuweit am 20.06.05 - 18:40:35
Hallo, auch auf die Gefahr mich jetzt als anfänger zu outen ;), ich würde nur gerne mal wissen, wie ihr so designtechnisch vorgeht, wenn ihr ein größeres Projekt planen müsst.
Ich hab jetzt die Aufgabe, mit Hilfe der Featurelist(Pflichtenheft vom Kunden) innerhalb einer Woche die Planung durchzuführen, so dass nächste WE die Implementierung beginnen kann.
Vieleicht noch kurz was zum Projekt, es geht um ein Bewertungstool für firmeninterne Schulungen mit diversen Statistiken und Reports mit einem Userpeak von ca. 1000, achja und sie soll auch noch lokal replizierbar sein.
Da ich mich für einen OO-Ansatz entschieden habe, wollte ich folgendermaßen vorgehen:
1. Use Cases + Diagramm unter Berücksichtigung des Sicherheitskonzepts definieren 2. UML-Klassendiagram auf Basis des Use Case-Diagrams erstellen 3. Alle Views und Forms (mit Klassenbezug) entwerfen und die Felder definieren 4. Methoden der Klassen aufführlicher definieren(also was sie genau machen sollen und wie) 5. Eventuelle Agenten definieren.
Ist das eurer Meinung nach eine sinnvoller Designprozess(auch im Hinblick auf die Reihenfolge)? Oder habt ihr vieleicht noch weitere Idee oder vieleicht auch wehemente Einsprüche ;) ? Ich bin für jedes konstruktive Feedback dankbar, vielen Dank schon mal im voraus!
Im Grunde finde ich es gut über use cases zu gehen. Meiner Ansicht nach sind weder Notes-Forms noch Notes-Views Objekte im Sinne von Smalltalk/C++/Java Objekten --> vor dem Hintergrund dieser Sprachen wurde UML entwickelt, bzw. weiterentwickelt. So dass es da evtl. einen missmatch gibt. Denke bitte auch an nicht-funktionale Requirements.
Ich würd mit der OOA Definition nicht zu weit ins Detail gehen. Gerade als Anfänger: Wenn du beim proggen merkst, dass du dich verplant hast, mußt du dann deine dolle OOAnalyse umschreiben und das macht irgendwann überhaupt keinen Spaß mehr.
Ausserdem halte ich kleinere Projekte einen iterativen Prozeß für sinnvoller. So wie du das schilderst, ist das kein großes Projekt. Großes Projekt ist für mich etwas mit >10 Mannjahre. Auch von der Aufgabe her, ist das kein großes Projekt. Werd aber nicht zu iterativ. Schliesse Sachen eindeutig ab. Ich bin derzeit ein bischen unter Feuer, weil ich in letzter Zeit ein bischen in meine schlechte Eigenschaft der 80% Lösungen zurückgefallen bin und die Leute haben Recht.
Was heisst Klassenbezug? Du willst in LotusScript Klassen programmieren oder du siehst die Forms and Views als Klassen an?
Letztlich ist UML ein Hilfsmittel, dass sehr unterschiedlich eingesetzt wird. Model Driven Architecture Leute sehen es als eine Art Programmiersprache an und mehr Agile geprägte Leute predigen die Anschaffung von Whiteboards und adHoc Modellierung zur Kommunikation von Ideen.
Es ist aber sehr gut, dass du dir über Dokumentation Gedanken machst. Es ist komplex und es gibt keine festen Regeln. Fang also nicht irgendwann darüber zu jammern an: "Das geht nicht in Notes". In Java geht es nämlich eigentlich auch nicht (meine Meinung. Kann mißverstanden werden. Ich bin UML-User).
Schalte deinen kritischen gesunden Menschenverstand ein.
Axel
Titel: Re: Größere Notes-Anwendung planen?
Beitrag von: jr am 20.06.05 - 19:18:57
Hallo Simon,
prinzipiell sieht das sehr gut aus. Wenn Du das tatsächlich von Anfang bis Ende so durchziehen kannst, ziehe ich meinen Hut. Ich mache seit über 10 Jahren Projekte mit Lotus Notes (und davor weitere 10 Jahre mit andern Progrmmiersprachen) und habe bisher noch nie Use Cases oder ein UML-Diagramm erstellen müssen (das habe ich zwar auf der Uni gelernt, hab's aber schnell wieder vergessen). Ich glaube nicht, dass sich das später irgend jemand noch einmal ansieht. Vielleicht noch die Datenbank in BNF beschreiben und die Korrektheit beweisen... ;)
Im Ernst: Ich spreche da wirklich nur für mich. Mein Problem ist, dass ich in meiner gesamten Eintwicklerzeit noch nie ein Projekt hatte, das tatsächlich so durchgeführt wurde wie es ursprünglich spezifiziert war. Immer gab es während der Entwicklung Erweiterungen, Veränderungen oder einfach nur neue Erkenntnisse. Vielleicht bin ich da auch einfach zu doof dazu und bei den anderen klappt das immer.
Meine Vorgehensweise war bisher immer der Bottom-Up-Ansatz. Also mit kleinen Moduln anfangen und diese sändig ergänzen und erweitern, bis das gewünschte Ziel erreicht wurde. Wenn mehrer Leute an einem Projekt arbeiten kannst Du so auch relativ einfach die Funktionalitäten aufteilen. Hierzu müssen lediglich die Schnittstellen sauber definiert werden.
Bei Klassen ist es genauso. Zuerst die Schnittstellen definieren, dann die internen Funktionen codieren.
Und noch ein Tipp aus meiner Erfahrung: Kommentiere so viel wie Du kannst im Code selbst, denn das ist wichtiger als alles andere. Nach spätestens 6 Wochen, wo Du den Code nicht mehr gesehen hast, weißt Du nicht mehr, was Du gemacht hast und musst Dich erst wieder durch den Code durcharbeiten. UML und andere Dokumentationshilfsmittel nützen da nur bedingt.
Ich weiß nicht, ob ich Dir jetzt damit ein bisschen geholfen habe, aber so habe ich es in den letzten Jahren kennengelernt. "Divide and conquer" ist mein Ansatz und ich bin bisher sehr gut damit gefahren.
Gruß,
Joachim
Titel: Re: Größere Notes-Anwendung planen?
Beitrag von: Simon Dotschuweit am 20.06.05 - 19:32:53
Vielen Dank schon mal für die schnellen Antworten :)
... Was heisst Klassenbezug? Du willst in LotusScript Klassen programmieren oder du siehst die Forms and Views als Klassen an? ...
Damit meinte ich, dass wenn die Objekte und ihre Beziehung untereinander feststeht, ich alle für alle Objekte (Dokumente), die der Nutzer selbst anlegen und sehen darf sozusagen als User Interface die Forms und Views auf Basis der Klassen definiere.
Also mir hilft sowohl UML als auch Use Cases schon. Klar wurde das von den Konzept-Consultants dieser Welt überhyped. Careful Diesmal mit der Extrapolation von eigenen Erfahrungen als Naturgesetze. Wobei ich das mehr zur Skizzierung von Ideen benutze, wie ich ein Problem angehe.
Darüber hinaus erlebe ich gerade, wie Leute für nicht kleine Bestandteile einer großen Anwendung mit einem stark Model Driven Architecture geprägten Ansatz mit Code Generierung aus Modellen Erfolg haben. Nicht in Notes.
Nur wurde das alles von den Konzept Consultings dieser Welt deutlich überhyped und von den happy naives from lala-Land gerne gegessen. Gerade davon kann man aber nicht auf eine grundsätzliche Irrelevanz in der Praxis schliessen.
Als Anfänger würde ich aber auch mit einfacheren Ansätzen anfangen und keine übertriebene Erwartungen an UML haben.
Gruß Axel
Titel: Re: Größere Notes-Anwendung planen?
Beitrag von: jr am 21.06.05 - 08:38:21
Hallo,
es ist sehr schwer, auf dieses Thema allgemeine Antworten zu geben. Ich denke, dass hier jeder seinen eigenen Weg gehen muss. Und was für den einen das Alleinseligmachende ist, kann für den anderen als absolut nutzlos angesehen werden.
Wenn man mit einer Methode klar kommt und damit glücklich ist, dann sollte man auch dabei bleiben, wenn man es kann. Oftmals sitzt da aber noch der Chef dazwischen, der hier genaue Vorgaben verlangt. Deshalb ist es sicher nicht verkehrt, wenn man auch die anderen Möglichkeiten kennt.
Wie oben geschrieben mache ich seit etwa 20 Jahren Projektarbeit und habe da verschiedene Ansätze kennen gelernt. Als Bereichsleiter Lotus Notes einer großen Discount-Kette habe ich dann damals ganz genaue Anforderungen an meine Mitarbeiter gehabt. Als ich dann das Unternehmen verlassen habe, hat mein Nachfolger einen komplett anderen Ansatz verfolgt und heute hat das mit dem was ich damals gemacht habe nicht mehr viel gemeinsam. Die Mitarbeiter sind aber die gleichen geblieben und die mussten sich dann halt entsprechend umgewöhnen.
Seit vier Jahren bin ich jetzt selbständig und habe dadurch den Vorteil, dass ich mir meine Regeln selbst auferlegen kann. Dass aber auch dies nicht das Optimum darstellt habe ich dann gemerkt, als ich einen weiteren Entwickler eingestellt habe, der dann plötzlich wieder ganz andere Ideen hatte.
Um das Ganze noch einmal auf den Punkt zu bringen: Man sollte über die verschieden Projektentwicklungsansätze bescheid wissen und für sich den Optimalen heraussuchen. Mit der Zeit wird man seinen eigenen Stil bekommen. Tipps von Kollegen sind da sicher hilfreich, aber eben immer nur Tipps.
Ich finde das grundsätzlich von Leuten, die OO mehr von aussen betrachten viel zu viel Wert auf die OO-Analyse gelegt wird und zu wenig auf OO-Development. Und weil sie dazu tendieren zu glauben, man müßte da grundsätzlich irgendwelche gewaltigen Domain Models modellieren, versuchen sie es nicht. Man kann sowieso nur Klassen modellieren, wenn einem wirklich klar ist, wie man das programmiert.
Das stimmt, ist eigentlich nicht nur in OO so. Erst wenn man eine Ahnung von den angestrebten "Mechanismen" hat, ist man überhaupt in der Lage, etwas so zu modellieren, dass es dann am Schluss auch Chancen hat, zu funktionieren.
Titel: Re: Größere Notes-Anwendung planen?
Beitrag von: Simon Dotschuweit am 28.06.05 - 10:18:06
Vielen Dank erstmal für die vielen Antworten!
Ich bin jetzt gerade beim Klassendiagramm und hätte da gleich mal eine Frage, macht es Sinn, alle Felder aus dem Dokument in der Klasse mit Setter und Getter Methoden abzubilden?
@Semeaphoros: Ich hab mal in deine beiden Beispiel DBs geschaut und da machst du da nicht so, kann daraus entnehmen, dass es unsinnig wäre und man lieber direkt auf die items im dokument zugreift?
Im Analysediagramm würde ich alle Felder als Attribute der Klasse modellieren.
Im Design kann ich das nicht so pauschal sagen. Spontan würde ich eine Aggregation von der Klasse zur NotesDocument-Klasse vorschlagen. Die NotesDocument-Klasse bietet schon Methoden an, mit denen du Feldwerte auslesen und setzen kannst.
Ferner würde ich eine Klasse/ein Modul erstellen, das die Feldnamen als Konstanten hält. Dann kannst du in der Anwendung über NotesDocument-Obkjekt und Konstanten auf die Feldwerte zugreifen.
Wie gesagt, in meinen Augen kann das Design unterschiedlich aussehen, je nach Bedarf.
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.
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
Titel: Re: Größere Notes-Anwendung planen?
Beitrag von: Simon Dotschuweit am 28.06.05 - 15:44:29
@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?
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.
Titel: Re: Größere Notes-Anwendung planen?
Beitrag von: Simon Dotschuweit am 28.06.05 - 16:37:47
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 ;)
Ich würde nicht soweit gehen, pauschal zu sagen, dass es nicht sinnvoll ist, sowohl die Notes-Funktionalität für Parent-Child-Beziehungen, als auch eine eigene Verknüpfungslogik zu nutzen.
Was spricht dagegen, etwas zu benutzen, was schon da ist? Und dessen Vorteile zu Nutzen? - mir fällt gerade nur der eine ein, dass ich die Antworthierarchie in Ansichten darstellen kann, naja, und dass es halt schon funktioniert.
Ein "durchgehender Ansatz" ist in meinen Augen auch, für alles, was wie eine Parent-Child Beziehung aussieht, die Notes-Funktionalität zu nutzen und für alles, was Notes nicht kann, das eigene Zeug.
Grundsätzlich richtig, Thomas, und wäre auch meine Antwort, nur, die Randbedingungen sind hier anders. Auch die N zu N Verbindung, die aus meinem Beispiel stammt, funktioniert und bringt ähnliche Funktionalität wie die eingebaute. Der Vergleich ist hier nicht allgemeiner Natur - wie Du ihn machst - sondern der Vergleich zweier realer Implementationen untereinander und die Frage, ob man das so mischen soll oder nicht. Kennt man die Innereien der beiden Beispiele, komme ich zu meinem Schluss, dass es in dieser Gegenüberstellung keinen Sinn macht, nicht jedoch, dass dieser Schluss generell so zu fällen ist.
Titel: Re: Größere Notes-Anwendung planen?
Beitrag von: Simon Dotschuweit am 30.06.05 - 11:05:12
@Semeaphoros:
Also ich arbeite mich gerade durch das BaseDocument und du verwendest doch das feld ViewMainEntry für die Kategorisierung in der View, oder? Also sowohl Hauptdokument als auch die Childdocs haben den gleichen ViewMainEntry.
Aber wozu braucht man dann diese Felder: ViewSecondEntry und ViewEntryExtension?
Ich hab mir einfach mal alle Dokumente in der Adressdb angeschaut und da ist immer nur der MainEntry gesetzt, die beiden anderen scheinen nicht genutzt zu werden, oder täusch ich mich da?
Kann sein, dass die Einträge im Beispiel nicht genutzt werden. Suche die Einträge doch mal über die Design-Uebersicht, dann hast Du die Antwort schnell. Die Sache stammt natürlich aus einer grösseren Applikation und wurde auf das Wesentliche reduziert, da sind Nebeneffekte denkbar. Mit dem ViewSecondEntry ist es möglich, das Dokument unter einem alternativen Begriff in der kategorisierten Ansicht anzuzeigen, bei der ViewEntryExtension müsste ich jetzt selber nachsehen, wo da der Zweck genau ist, ob das die beiden Kategorie-Einträge modifiziert oder ob das dazu dient, Inhaltsinformationen in den Ansichten anzuzeigen ..... Wenn Dus nicht findest, sags nochmal, dann schau ich rasch nach.
Titel: Re: Größere Notes-Anwendung planen?
Beitrag von: Simon Dotschuweit am 30.06.05 - 11:45:38
Heißt das, dass er erst schaut ob es eine alternative kategorisierung gibt und wenn nicht, dann nimmt er die main. In jedem Fall aber wird eine Extension dazu geadded, wenn die also nicht leer ist, dann gäbe es quasi für jedes dokument das zwar den gleichen main / second entry aber unterschiedliche extension hat jedes mal eine neue Kategorie.
Jetzt würde mich nur noch der Hintergrund interessieren, warum du es so implementiert hast und nicht z.B. einfach ein Array genommen hast, in der alle ViewEntries drinstehen, dann könnte man doch beliebig viele vers. kategorisierungen mit absteigender prio haben, oder hab ich mich da vertan?
Du fragst mich etwas, was interessant wäre zu beantworten .... ;D
Was da genau dahinter steckte, weiss ich tatsächlich nicht mehr auswendig. Gegen einen Array hat irgendwas mit der N zu N Verlinkung zu tun gehabt. Wobei natürlich auch die verbessert werden könnte. Ich glaube mal, die Sache wird dann extrem schwierig, wenn wir Dokumente in Ebene 3 haben. Das Problem ist hier, dass wenn ein Mutterdokument - egal ob in Ebene 1 oder Ebene 2 - den Schlüsselwert (Kategorie) verändert, muss das in allen abhängigen Dokumenten nachgezogen werden. Aus der Natur der Ansichten heraus reicht es auch nicht, dass das Dokument in der 3. Ebene nur sein Mutterdokument kennt, es muss auch das Hauptdokument kennen. Irgendwo in der Ecke gibt es dann Probleme - die aber bestimmt nicht unlösbar sind - wenn man mit Arrays/Multivalue arbeiten möchte. Wie gesagt, das ist jetzt nur aus dem hohlen Bauch heraus und könnte auch von einer anderen Ueberlegung herstammen.
Ah, offenbar ist in dieser View die Version drin, die nur den Kurznamen anzeigt, wenn der definiert ist und nicht der Hauptname. War ein Kundenwunsch. Hier die bessere Formel, die versteht man auch leichter:
Genau den Gedanken hatte ich auch. Das Ding ist uralt und da ist wohl etwas an Leichen drin hängen geblieben von früheren Versuchen. Bevor die ViewEntries in den Dokumenten vorberechnet abgelegt wurden, wurde die Ansicht echt kompliziert berechnet und mit wachsenden Bedürfnissen und Ausnahmen ist die Formel gewachsen wie wild. Da ist dann beim Vereinfachen der "Optimizer" nicht mehr ganz fertig geworden ....... ;)
Ach, ich hab immer geglaubt, das passiert nur mir ..... ;D
Titel: Re: Größere Notes-Anwendung planen?
Beitrag von: Simon Dotschuweit am 01.07.05 - 20:03:29
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 ;)
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?
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
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:
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.
Ob dafür "Kapseln" der richtige Ausdruck ist, sei dahingestellt :)
Alles, was in der Funktionalität der Maske User-Interaktion erfordert, also sämtliche zusätzlichen Dialogboxen (bzw. deren Steuerung) oder komplexere Auswahlverfahren, bei denen der Inhalt der Auswahlliste vorberechnet werden kann und man den Code nicht unbedingt in die Maske packen will.
Einverstanden, es ist Geschmackssache, ob man das alles mit in die Maske packen will oder nicht, sobald man dann aber solche Funktionalitäten auch für das Bearbeiten mehrerer Dokumente benötigt, heisst über eine Auswahl in einer View oder so hast Du sonst keinen naheliegenden Platz, den Code abzulegen. Abgesehen davon lässt sich so UI-Code sowohl in Forms wie in Views/Folders einsetzen (reusability war doch mal so ein Schlagwort :) ).
Nur so als Schtichworte ohne jetzt tiefgreifend darüber nachzudenken. Es hat sich jedenfalls für mich bewährt, aber Du weisst ja, es gibt viele Wege nach Rom.
Ach, da kann ich dann auch gleich dazu sagen, dass es bei mir normalerweise auch keine Custom-Classes zu den Views gibt. In der Biz-Logik braucht es das in der Regel nicht, und im UI packe ich das alles in die dazu passende UIDoc-Klasse, da diese sowieso in der Regel recht übersichtlich bleibt.