If I understand you correctly:

Class A: MainBLL class is declared and used within a form, and is your business logic component?
Class B: clientObject class (2-way communication with other program) 'Is essentially the API for another app?
Class C: OrderDetails class Is the information captured from the form, and now needs to be sent to the other application via Class B?

In that case, You could use either option 2 or 3. Which way you go would depend upon how complex your code is to perform the send via Class B. If it is a simple method call on an instance of B with some parameters consisting of the data you need to send, you might as well just do it as a method of Class A.

If, on the other hand, there are complex transformations or other logic required to render the data compatible with Class B, you MIGHT create a separate class to do so, if only for the purpose of encasulating that code for re-use, and to potentially simplify maintenence.

The result of such an approach would be maintaining object simplicity at the cost of increased project complexity.

This feels like one of those areas where there is no right or wrong way - in the end it is a judgement call on your part. And you may find later that, whichever approach you took, the OTHER way now makes more sense. In that case, you can always re-factor to suit.

I would probably start by putting the SendOrder method as a Method on Class A. Then, if it looked complicated, and might be code that I need to maintain (or even better, if SOMEONE ELSE needs to maintain), I would examine moving it to it's own class.

Hope that made sense . . .

RWS