We're looking at implementing some processes using Guide Procedures, and I have a question about design 'style'.
I'm creating a data layer using Entity Services. The entity services will be utilized by the Application Services to create a business layer. How to do this is clear, and straightforward.
However, where I have a question is how the automatically generated Web Dynpro application (or any other Web Dynpro application, for that matter) can interact with Application Services. I've seen sample applications where the Web Dynpro application interacts with application services via mapping from the Web Dynpro interface layer through the GP Runtime - from my perspective, this looks like a good way to deal with a small amount of data being passed between the steps in the GP.
The primary Web Dynpro application will let the user interact with the data, massaging it until it's in a form where the next person needs to deal with it. I was thinking of having the Web Dynpro application interact with the Application Services layer directly to move data from the database to the web dynpro application, and back again. The only thing that would be passed between the steps in the GP would be the guid of the primary data structure. I would also expose a method of the Application Service as a CO which would take the guid and return the entire business object, so viewing screens could be constructed - as well, PDF's could be generated, and so on.
Is this considered bad form in a GP, specifically accessing Application Services directly, instead of through a step in the GP? I understand that what I want to do ties the Web Dynpro application directly to the Application Services layer, but my thinking is that the CO that encompasses the Web Dynpro should be 'atomic', in that all operations related to that specific step should be contained in a single CO. In other words, the action of creating the business object, fiddling with it, an then submitting it upstream should be contained in one CO.
Comments, suggestions?