The 3 options yield the "same" results, however, depending on needs, one requires more work on your part than the other. With Relationships, for example, Cache automatically handles all referential integrity for you (foreign keys are automatically generated for you). Whereas the other options don't provide that and you're required (depending on your needs) to code the referential checks (e.g. declare foreign keys).
Relationships load a "collection" of pointers to the members of the relationship. Objects are loaded to memory only when accessed. Pretty much how Arrays work as well. In essence Arrays and Relationships work the same. Relationships provide the extra referential integrity.
You're on the right track, however, depending on your needs, always prefer a relationship over a "plain" array/list. One of the biggest benefits is the referential integrity you get "out of the box".
Parameters being passed to a SOAP operation are also defined as properties in the generated class. In your override method, the "proxy" parameter will have a property matching the name of Obj1 and Obj2 parameters. Given your example the following should work
Method override(proxy As %SOAP.ProxyDescriptor, tag As %String)
{
....
W proxy.Obj1,!
W proxy.Obj2,!
........
}
Out of curiosity, why would you need to have a calculated field for this setup? You can always access the properties on ClassC with the following query
SELECT BRecord->Record->Propx FROM SQLUser.ClassC