on 10-20-2008 3:21 PM
I am thinking in putting the bapi's call in an assistance class.
I read the Reginas comments at and I have some doubts.
Due to each WD Component can have only one assistance class, I'd like to put some methods that not access the database in that class too.
I'm worried about the size of that assistance class. I think it will get very big.
What should I do in terms of architecture?
Should I create others classes or others web dynpro components?
Thanks a lot.
You can create another class and create static methods to make it more readable
Abhi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No need for them to be static at all...it really depends on what you need and how you want to structure it.
If you think of your assistance class as your Model's "access point", then you could have in it some attributes which could be another classes instances...those instances could be created themselves in the assistance class constructor, or they could be created and returned to WD controller on request, by assistance class methods...
The BAPI you're calling most probably belongs to a business object as a sales or purchase order...so you could create a class for it (e.g. ZCL_SALES_ORDER) and in the SAVE, READ, etc. method (depending on what you're doing) call the BAPI.
The point to remember when creating classes is the concept of separation of concerns.
That said, what may appear initially way too simple to justify being developed into separated classes may lately evolve into a big class which does everything, requiring some refactoring.
That was my previous post explanation...maybe I was not clear enough.
You can't have more than one assistance class defined per component...so, either you use it as a single "access point" to get references to other model classes, or you instance and use those other classes directly from WD. Nothing wrong with that...the assistance class advantage is just that it is instantiated by the framework, but it is fair enough to separate some overly complex logic into several separate classes.
Edited by: Alejandro Bindi on Oct 20, 2008 1:40 PM
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.