Dynpros und OO - Königsweg gesucht

Dynpros und OO - Königsweg gesucht

Moin,

ich frage auf der Suche nach Anregungen mal herum, wie andere das so machen:

Gegeben sei eine Anwendung mit getrennten Layern für Application Controller, Business Logik und Persistenz. Der Anwender soll (derzeit) per SAPGUI mit dem Programm kommunizieren.

Welchen Weg geht ihr da? Ich hab alles schon gesehen, bis hin zu gigantischen Dialog-Controllern, die sich beim Application Controller als observer registrieren und eine Hammer-Stageverwaltung brauchen, um dann 1-2 Dynpros darzustellen.

Wichtig ist mir, dass der Dialog keine Programmfunktionen ausführt, sondern ich jederzeit statt eines Dialoges einen Workflow oder statt der SAPGUI ein Fiori draufsetzen könnte.

Auf Anregungen gespannt


Ralf

Re: Dynpros und OO - Königsweg gesucht

Hi,

eine sehr interessante Frage wie ich finde. Ich befürchte allerdings einen wirklichen Königsweg gibt es nicht. Ich beschäftige mich mit dem Thema auch schon ziemlich lange und habe da die unterschiedlichsten Dinge ausprobiert. Bus-Screen Framework, verschiedene Ansätze aus dem SDN. Das MVC-Pattern habe ich auch nicht so wirklich verstanden, bzw. hab' mich immer gefragt was der Controller da eigentlich zu suchen hat.

Ich bin letztendlich bei dem Presentation Model Pattern gelandet. Ich finde das eigentlich ziemlich elegant, da man hier tatsächlich jede Art von Gui drüber stülpen kann. Meine Motivation war jedoch eine andere und ist meiner Meinung nach auch das entscheidenendere, nämlich das ich damit auch einfach Unit Tests für die Anwendung schreiben kann ohne irgendeine Gui zur Verfügung haben zu müsssen. D.h. man könnte die komplette Anwendung entwickeln ohne auch nur einen Screen zur Verfügung zu haben. Ich habe hier mal ein Link zu einem wie ich finde sehr guten Microsoft-Artikel, der die unterschiedlichen Ansätze sehr gut beschreibt.

https://blogs.msdn.microsoft.com/erwinv ... -patterns/

Ich habe das ganze allerdings auch erst ein einziges mal wirklich eingesetzt, fand es aber gut anwendbar. Meine Anwendung hatte ganz vereinfacht gesprochen eine Kalkulationsstruktur, mit mehreren Stufen abgebildet. Die Screens werden wie gehabt in der Funktionsgruppe abgebildet. Das "Rendern" der Kalkulationsstruktur, also wie das dargestellt wird, erfolgt in lokalen Klassen innerhalb der Funktionsgruppe mit dem ALV-Tree, da dies ja unabhängig von der eigentlichen Anwendung ist und ja auch nur für eben genau für die SAPGui gebraucht wird.

Die eigentlich Kalkulationsstruktur, also in welcher Beziehung/Hierarchie stehen die einzelnen Kalkulationen zueinander, welche Werte besitzen sie und welche Operationen können darüber abgebildet werden stehen dann im Presentation Model. Im konkreten Fall eine globale Klasse. Anwendungslogik und Persistenz stehen dann wiederum in einer separaten globalen Model Klasse.

Ich fand' den Ansatz gut, insbesondere der Möglichkeit der Unit Tests. Ob das jetzt der Königsweg ist. Keine Ahnung. Liegt bestimmt auch am persönlichen Geschmack.

Off-Topic:
Vielleicht noch ein Wort von mir zu Fiori. Fiori macht aus meiner Sicht nur wirklich dann Sinn, wenn Du diese ganzen Annotations aus den neuen CDS-Views nutzen kannst und Du Dir die Screens automatisch darauf basierend rendern Lässt. Erfahrungemäß will der Anwender dann doch was anderes. Unabhängig davon halte ich es für eine Toy-Gui für Smartphones und Tablets. Ein professionelles arbeiten ist damit aus meiner Sicht nicht möglich. Das sieht man z.B. an dem völlig desaströsen Auftritts des "Neuen" SDN's. Leider sehen das einige SAP-Verantwortliche völlig anders.

Viele Grüße,
Tapio