他のシステムで使用できる製品を構築しています。SOAなので、サービス（WCF）のみを開発しています。そのサービスのインターフェースを設計する方法について、物議を醸す議論がいくつかありました。サービスの手続き型設計と OO 設計のどちらかを選択しています。
当社のサービスは.NETやJavaから利用されるため、オブジェクト指向設計だとサービスとの統合が難しいという声があります。サービスはOOアプローチを使用してはならないと考える人もいます。OO はまったく問題ないと言う人もいます。その結果、明らかな落ち込みはありません。
WCF は両方のデザインを使用する簡単な方法を提供しますが、何が最適ですか?
あなたが使用している「オブジェクト指向」の定義は、「オブジェクト」を管理するプログラムの概念であり、これらの個々のオブジェクトは内部状態を管理し、呼び出される関数を公開していると思います。
これに最も近い WCF の並列は、各サービス インスタンスの有効期間がクライアントによって制御されるセッション ベースのサービスです。
このサービスを Java で呼び出す場合は、basicHttpBinding を使用する必要があります。これは従来の Web サービス プロトコルを使用するためです。
このバインディングはセッション ベースのサービスをサポートしていないため、文字通りセッション ベースのサービスを使用することはできません。
したがって、サービス自体に関して「オブジェクト指向」パラダイムを適用することはできません。
「私の質問は、サービスのメソッドがスカラーパラメーターではなく複合型を受け取る必要があるかどうかについてです」と言って、元の質問を明確にします。
次のことを自問してください。
a）OO以外のクライアントがサービスを使用する可能性はありますか？Dunno、COBOLバッチ？あなたの会社がOOtech（Java / .NET）で標準化したとしても、この特定のサービスが将来、外部エンティティ（顧客、PHP Webサイトなど）によって使用される可能性があります。
b）過去にそのようなサービスをすでに多数作成しましたか（したがって、複雑なタイプでマーシャリング/シリアル化/逆シリアル化の問題がないこと、または少なくとも安全に使用できるものを認識していることを完全に確信しています）？
両方の点に完全に自信がある場合は、サービスの入力と出力の両方を設計する際に「OO」アプローチを自由に使用してください。それ以外の場合は、最も安全な（より原始的な場合）アプローチを選択し、「オブジェクト」をスカラーのグループに分解します。