0

何がベストプラクティスなのかわかりません。
大きくて複雑なオブジェクトがいくつかあります (フラットではありません)。
そのオブジェクトには、多くの関連オブジェクトがあります。たとえば、Invoice はメイン クラスであり、そのプロパティの 1 つは InvoiceSupervisor です。これは、User と呼ばれる独自の大きなクラスです。
ユーザーは、フラットではなく、部門プロパティ (部門と呼ばれるオブジェクトも) を持つこともできます。

たとえば、新しい請求書を作成したいとします。

最初の方法:
クライアントに入力するフィールドをいくつか提示できます。そのうちのいくつかは、使用可能な値を入力する必要があるコンボになります。たとえば、利用可能なinvoiceSupervisors。次に、選択したすべての値をサーバーに送信し、サーバー上で新しい請求書を作成して、選択したすべての値をその新しい請求書に割り当てることができます。次に、新しいスーパーバイザーを割り当てる必要があります。選択したユーザーを、ユーザーがサーバーでコンボボックスから取得した ID でプルします。ユーザーが請求書の監督者に該当する場合など、ユーザーに対して何らかの検証を行う場合があります。次に、User オブジェクトを InvoiceSupervisor に割り当てます。次に、すべてのプロパティを入力したら、新しい請求書を保存します。

2 番目の方法:
最初に、サーバーを呼び出して新しい請求書を取得できます。次に、クライアントで選択したすべての値を入力できます。たとえば、サーバーを呼び出して新しいユーザー オブジェクトを取得し、コンボボックスからその ID を入力して、ユーザーを InvoiceSupervisor として割り当てることができます。クライアントで Invoice オブジェクトを入力した後、それをサーバーに送信すると、サーバーは新しい請求書を保存します。サーバーを保存する前に、いくつかの検証も実行できます。

では、クライアントでオブジェクトを作成してサーバーに送信するか、クライアントからすべての値を収集し、それらの値を使用してサーバーで新しいオブジェクトを作成するのが最善の方法ですか?

4

1 に答える 1

1

ビジネス処理の複雑さの観点から考えてください。

必要なのは、クライアントが新しい請求書を作成することです。これを行うために、クライアントはいくつかの異なる入力パラメーターを提供し、プロセスを呼び出して応答を取得します。これが最初のシナリオです。シンプルで明確。

一方、2 番目のアプローチには、通信プロトコルが含まれます。これをください。応答として何かを提供し、それから別の何かを提供します。これは不当に複雑に聞こえます。ある時点で通信が切断されたときに何が起こるかを注意深く調べる必要があります。分散トランザクションを含める必要がありますか? はいの場合、そのような複雑さが本当に必要ですか?

その場合、最初のシナリオを選択します。クライアントとサーバー間の契約を不必要に複雑にしないでください。

于 2012-11-22T10:58:43.367 に答える