I’m working on a web service that is basically a wrapper around an Oracle Stored Procedure and it currently has 11 parameters. It’s not that there are 11 arguments, but I feel there should be a structure to place at least a few of them in in-order to keep good architecture. All parameters are required to be passed, but code readability suffers from such a long call.
The service is to report a successful download that our client application makes from a 3rd party company so that we can keep track of our billing (both with the client and the 3rd party).
In short, it’s 3 Guids, 5 ints, an int[], a double[], and a string. The two arrays are parallel.
If it changes anything, the back-end service is .Net 4.0 WCF Service but the application making the request will be .Net 2.0 Windows Form Application.
What kind of business relations do you warrant coupling together into objects? What would be the optimal way knowing that this is being transferred using SOAP?
In such a case, when you have more than 2, 3 parameters, I would wrap those up into a
(YourOperation)Requestobject. It’s easier to create one of those, set the necessary properties and then pass thatRequestobject into your WCF call (and possibly get back a(YourOperation)Responseobject from the call).