2

私たちはSOAエンタープライズに向けて努力しています...

メンバーの詳細を更新するための 3 つのオプションが与えられた場合、どのように契約を設計するのでしょうか?

ビジネスプロセスは非常に簡単です。顧客が電話 (または自分でログイン) し、個人情報を更新して、最新の詳細を入手できるようにします。顧客の雇用主は、メンバーの詳細を提供することもできます (これは一括で行われます。一度に数十から数千になる可能性があります)。これは、将来的に彼らと正しく通信できるようにするためです。複数のバックエンド システムがあります。

詳細は次のとおりです。

  • 電話番号、
  • 住所、
  • Eメール、
  • 名前または会社名、
  • 連絡窓口、
  • タックスファイルナンバー、
  • 配偶者の有無
  • 喫煙者の状態

現在のところ、ビジネス ルールは次のとおりです。 有効なタックス ファイル番号が既に提供されている場合は、再度提供することはできません。(オーバーライド可能) 有効な住所の詳細が存在する場合、雇用主はそれらを更新できず、初回のみ提供します。

オプション 1: 1 つの操作、Member.UpdateDetails

  • 作成および管理するサービスは 1 つだけです。
  • ビジネス ルールが大きくなると、このサービスのまとまりが失われる可能性があります。
  • 何かを削除する必要があることを指定することと、そのままにしておくことを区別しなければならないという問題があります。
  • 単一の作業単位、単一のトランザクション。

オプション 2: 4 つの操作に分割します。Member.UpdateContactDetails; Member.ProvideTaxFileNumber; Member.UpdateName; Member.UpdateDemographics

  • 単一の操作を簡素化する可能性があります - 複雑さを 4 つの操作に分散させます。
  • 何かを削除する必要があることを指定することと、そのままにしておくことを区別しなければならないという問題がまだあります。たとえば、結婚歴なしで喫煙者のステータスのみを指定したい場合はどうでしょう。
  • これらを正しくグループ化する方法を理解するには、詳細な分析が必要 - まとまりはビジネス プロセスによって異なります。
  • 作成および保守するサービスが増えました。
  • トランザクションが問題になる - 発信者によって複数のトランザクションが処理されますか?

オプション 3: より小さなスチルに分割します: Member.UpdateAddress; Member.UpdateBusinessDetails; Member.UpdateContactNumbers; Member.UpdateContactPerson; Member.UpdateEmailAddress; Member.UpdateMailingAddress; Member.UpdatePhysicalAddress; 等

  • 何かを削除する必要があることを指定することと、そのままにしておくことを区別しなければならないという問題を取り除きます。
  • ビジネス ルールは、どのような操作でも簡単に進化できます。
  • 作成および保守するサービスの負荷。
  • トランザクションが問題になる - 多くのトランザクションが発信者によって処理されますか?
  • プロパティ セッター / CRUD のように見え始めます - どうやらダメです。

オプション 1 または 2 で、発信者が自宅の電子メール アドレスのみを更新したいとします。クライアントがメッセージ全体を完了するとは期待できません。クライアントは他のすべてのタグを除外しますか? この問題に対処するための、受け入れられている明白で直感的なパターンは何ですか?

これが実際にパターンである場合、クライアントはどのようにフィールドをクリアするか、または null に設定しますか? .NET では、サーバー コードで、提供されていないものと null を区別する明確な方法がわかりません。明らかではないので、これは受け入れられないパターンだと思います。

4

3 に答える 3

1

粒度の細かい引数を持つ粒度の粗い API を使用します。フィールドを更新したくない場合は、それを示す記述子をデータとともに渡します。何かのようなもの：

Result updateMember(Member member, List<String> fieldsToUpdate)

細粒度の API を持つことは、トランスポートがしばしば不明瞭になるため、基本的に死に至ります。

誰かが書いた場合:

UpdateContactNumbers(...);
UpdateAddress(...);
UpdatePersonalDetails(...);

彼らはおそらく、a) ネットワーク経由で 3 回の旅行を行い、b) DB への 3 回の旅行を行い、c) DB での 3 回のトランザクションで締めくくっています。これは、関連するマーシャリングとアンマーシャリングの楽しみのすべてをカウントしているわけではありません。

もちろん、これは正気ではありません。

サービス API はリモートである必要がありますか? いいえ、もちろんそうではありませんが、多くは透過的であり、最小限、多くは透過的です (ローカルまたはリモートである可能性がありますが、わかりません)。

そう。粗い API、きめの細かい引数。やりたいことを詳細に把握し、すべてを一度に実行します。

于 2011-12-06T22:55:55.133 に答える
1

2 番目のオプションを強くお勧めします。これは、変更を行うユーザーの意図が、それに作用するコードに至るまで保持されるためです。

最初の利点は、「DTO で削除を表すにはどうすればよいか」という質問に答える必要がなくなることです。これは、その事実をDeleteContactNumberメッセージとして明示的にキャプチャできるためです。

2 番目の利点は、「一度に複数のアドレスを追加するにはどうすればよいか」という質問に答える必要がないことです。変更された DTO から誰かがアドレスを追加したと推測する必要がないため、AddContactAddressメッセージが表示されます。

3 つ目の利点は、DTO の分析を行ってそれを推測しなくても、発生するイベントが何であるかを知ることができるため、1 日の終わりにより興味深いビジネス分析を行うことができることです。

最後に、特定のイベントに情報を追加するのが簡単になります。連絡先アドレスを削除する理由を知りたいですか?

「データをフェッチし、データを変更し、データを保存する」というモデルを使用すると、コードの行数が少なくなりますが、最終的には、システムで処理が行われる理由を理解することが難しくなり、最終的にコストがかかります。

于 2011-12-06T19:51:37.437 に答える
0

個人的には、UpdateMember 機能と UpdateAddress などのより単純な機能の両方を使用することにあまり問題はないと思います。異議を唱える人もいるかもしれませんが、これは完全に受け入れられると思います。

ここでは「直感的」という言葉が適しているかもしれません。あなたにとって何が正しいと思いますか?

私には、UpdateMember が確実に含まれる候補のように思えます。このサービスが UI によって使用されている場合、おそらくすべてのフィールドは GetMember 呼び出しによって既に取り込まれている可能性が高いため、いずれにせよすべてのフィールドには元の値が取り込まれます。UI でなくても、同様のものを使用できる可能性があります。次に、より単純で特殊な状況のために、UpdateAddress、Update PersonalDetails も使用できます。

ただし、私が気に入らないのは、UpdateMember 機能のみを持ち、変更したくないフィールドを空白のままにしておくというこの考えです。多くの人がこのパターンを使用するとは思いませんし、私も絶対に使用しません。あなたが言うように、フィールドをnullに設定するにはどうすればよいですか。

于 2011-12-06T15:42:19.150 に答える