Skip to Content
author's profile photo Former Member
Former Member

OO-Transaction - Dynpro or MainClass as Controller?

Hello,

I've got a question about programming style concerning Object Oriented Transactions:

There are two possibilities for me, here is a small example. I hope you understand what my question is about:

1. Class as Controller

Creating a Class "MainProgram" which calls FunctionModule "Screen1" to show a dynpro "InputScreen". Dynpro "InputScreen" does all the things to ensure, that the Userinput ist consistent and all right. FunctionModule "Screen1" Returns all the UserData to the Class "Mainprogramm". The Class "Mainprogramm" now does some DataBase stuff and Calculating things.

After that it calls FunctionModule "Screen2" to show a Dynpro "CommittingScreen". This Dynpro asks the User whether the Calculated Data is allright. The User also can change some Fields and then push a Button "Save", "Back" or "Cancel". The FunctionModule "Screen2" returns the answer and the changed data back to the class "Mainprogramm" which performs the appropriate action (which is saving data or Calling FunctionModule "Screen1" again or "Leaving Program").

If the required user action is "save Data on Database" the last call of Class "Mainprogram" ist FunctionModule "Screen3", which calls Dynpro "Resultscreen". Here the user can end the program by clicking "end program" after he saw the results. FunctionModule "Screen3" now tells Class "MainProgram" the action ("end program") and the Class ends the Program.

Of course in this Example all FunctionModules are in the same FunctionGroup.

2. FunctionGroup as Controller

The 2nd Example starts also with Class "Mainprogramm" which only Calls FunctionModule "AllScreens". "AllScreens" Calls Dynpro "InputScreen" and after the User did his Input an PAI Module Calls a Local Class to do all the Database and Calculating stuff. After that the Dynpro Module Leaves to Screen "CommittingScreen". Now the User does his changes. The PAI-Module of the "CommittingScreen" again uses a local class to do all the things and sets the next screen according to the UserInput (Leaves to Screen "Input Screen", . Ans so on.

You see: In the First Example all the Controlling-Stuff is done by the Class "MainProgram" whereas in the 2nd Example the Controlling is Programmed in the PAI and PBO Modules of the Dynpro.

If now there should be a new UserInterface, in example 1 i just have to change the function modules and tell those who build the new Interface: "In screen1 i expect the following user data: X Y Z" "In screen2 i give table A to the interface and expect an answer and a corrected table back" and so on. In example 2 i had to copy the local classes which do all the database and calculating stuff from the old dynpro to the new user interface.

So i think example 1 is better - but it doesnt use the advantages of dynpros (Leave to Screen....) because this is done by the "MainProgram" Class....

Can you tell me what is recommended by SAP ? In the ABAB OBJECTS book, i saw an example which was designed like the 2nd example. What is your style and what do you think is better according to Maintanence.

Thanks for your ideas!

Regards!!!!

Christopher

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

1 Answer

  • Posted on Dec 08, 2011 at 09:39 AM

    Hello Christopher,

    at least, you should consider using some architectural princilpes: Loose coupling and separation of concerns.

    E.g. try to encapsulate every object in our scope with small classes and link them together by using interfaces.

    For SAP dynpro development, I would at least try to encapsulate everything in classes and hold only the dynpro within a function group, due to the technical limits, that dynpros can only exists for function groups and reports.

    Next: build a central application class and a generic controller class for the dynpro processing. Every dynpro should encapsulated via a class and every sy-ucomm should be a simple and small class which deals with your data. The generic controller has to bring the views, events and the model together. The model will be delivered by the central application class.

    Before you are starting to build your own framework, just look at this http://wiki.sdn.sap.com/wiki/display/ABAP/SAPmvc.

    The SAP mvc-Framework delivers the functionality, which should fulfill your needs.

    The introduction has been made with this blog: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/10732. [original link is broken] [original link is broken]

    Hope this helps you.

    Kind regards,

    Hendrik

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.