My simple question is, is it good practise to pass more than one ProDataSet as a parameter?
Imagine the scenario where you have a Data Access program that returns a PDS containing all the information for a particular order. And you have another DA program that returns a PDS with all the information about a particular customer.
Now you have a front end program that wants to display all the information about customer ABC and also the last order this customer made.
So, my Business Logic layer goes off to the DA layer and gets all of the information about the customer in a PDS and then goes back to get all the information about the order in a PDS. What, then would you return to the front end? Two separate PDSs or would you merger the two into a single, bigger PDS?
Or, taking a different slant, would you write a whole new DA program from scratch that just returns a big PDS with order and customer info?
Imagine that this is the only time that the PDS will be used (i.e. there would be no reuse of a big customer/order PDS anywhere else).
Thanks for any help!
First, of course, I wouldn't pass any PDS. I would pass entity objects.
But, if your use case really is all info about one customer and all info about one order, then, yes, I would probably handle that with two entity objects or two PDS.
If, instead, the use case was date and dollar value only of the last 10 orders, it might be more tempting to add it to the Customer, but I think I would still handle it as two.
The only real link here is the customer ID. Other than that, the data in each are entirely about something very different. That is a strong clue that they should be separate.
In particular, one imagines a button in the UI to retrieve the details on the order prior to the one displayed. One certainly wouldn't want to re-fetch the customer information.
Thanks,
My initial feeling was that it would be more logical to pass 2 separate PDS. Now that you mention getting information about extra orders then that makes even more sense to pass in 2 separate PDS.
However... "entity objects"... hmm...
::Goes off to find some documentation::
You aren't likely to find much in the way of documentation on entity objects in the ABL docs. The closest you are likely to come is in AutoEdge and the associated whitepapers, but they are heretical since they pass PDS.
But, it is a well-established concept in OO generally. Just wrap the PDS or TT in an object and provide methods for accessing and manipulating the data. You can't pass that object across the wire, but you can serialize it to XML or return the PDS via a method for the sake of transmission and then use that to initialize the update object on the client end. If you serialize via XML, then you can send the same data to a number of different client functions, each with its own Customer object that does different things with the information and it is easy to parse the data to get the parts that are relevant to that function.
Note also how well this fits with sending the data across Sonic.
First, of course, I see no problem in passing arount PDS's.
My simple question is, is it good practise to pass more than one ProDataSet as a parameter?
When you are talking about s network layer (i.e. AppServer or Sonic) between UI and BL/DA it's definitively a good practice to pass more than one ProDataSet as a parameter per request. No matter if it's input or output.
One of the most common mistakes I've seen people do with distributed apps was to design them in a way that the initialization of a single UI (and that's often what hurts the users most) required much more than 20 AppServer requests... Even in a LAN that's not ideal. Using VPN/WAN that's a catastrophe. Think of a ping time of 50 msec, that makes 20 smalll network packages per second. Depending on your AppServer configuration, each AppServer requests takes (depending on your configuration) a minimum of two network roundtrips (I guess guaranteed delivery with Sonic is no better). That make a max of 10 requests per second on a good WAN connection.
But it should be a task for a service adapter/service interface to take care of call bundeling. You shouldn't desing your business or data access logic in that way. And you shouldn't write that with a particular UI in sense - try to find a good compromise between what's good for the UI and potential non UI service requesters - and also the BL.
The call optimization is a separate topic and should be done outside the BL.
Many people won't believe it, but the ADM2 both in accessing SDOs and Business Entities is a very good sample for that (aka one hit wonder). When designing the UI and the BL you don't need to consider this call optimization. It's done "magically" between service adapter and service interface. So it will also adust automatically when the UI changes.
Some data may even be cached. Also that can generally be solved at the service adapter/service interface levels.
tamhas schrieb:
Note also how well this fits with sending the data across Sonic.
Don't forget that a ProDataset input/output parameter can also be send with Sonic. No manual bothering with XML required.
Needs testing for me ... READ-XML and WRITE-XML sounded so cool when first announced, but there seem to have been a lot of people struggling with them any time they needed to go in or out of ABL, so I'm a little cautious.