4

サービス指向アーキテクチャでアプリケーションを開発する際に、サービス コールのプロトタイプ/シグネチャを定義するベスト プラクティスは何ですか。

たとえば、メールを送信するためのサービス呼び出しを作成したいとします。

ドメインレイヤーに次のオブジェクトがあるとしましょう

 [datacontract]
public class Email
{
      public string To { get; set; }
      public string From { get; set; }
      public string Message { get; set; }
      public string Subject { get; set; }

      //I am not going to use this properties in send email method
      public string OtherProp1 {get; set;}
      public string OtherProp2 {get; set;}
      public string OtherProp3 {get; set;}

  }

次のようなサービスメソッド署名を作成する必要があります

   public bool SendEmail(string from,string to, string subject,string message){//My Logic}}

または

   public bool SendEmail(Email myEmail){//My Logic}

私は最初のオプションに傾いています。

4

6 に答える 6

3

私もアプローチ＃2に投票します。

「サービス指向アーキテクチャ」について言及したのでDataContract、クライアントに表示されるものを完全に制御するには、 を作成する必要があります。

ここでは、シリアル化はオプトインであるため、「未使用のプロパティ」はネットワーク経由で送信されません。

さらに、シリアル化されたメンバーの順序の制御、フィールドが必須かどうかの指定、カスタム名、バージョン管理など、他の利点も得られます。クライアントにとって物事が明確になるだけです。

また、DataContractSerializerは よりもおそらく 10% 高速ですXmlSerializer。詳細については、このブログを参照してください。ただし、アプローチ #1 (プリミティブ型) がXmlSerializerorを使用するかどうかはわかりませんDataContractSerializer。

[DataContract(Name="MyEmail", Namespace="http://contoso.org/soa/datacontracts")]
public class Email
{
  [DataMember(Name="ToField", IsRequired=true, Order=0]
  public string To { get; set; }

  [DataMember(Name="FromField", IsRequired=false, Order=1]
  public string From { get; set; }

  [DataMember(Name="MessageField", IsRequired=true, Order=2]
  public string Message { get; set; }

  [DataMember(Name="SubjectField", IsRequired=false, Order=3]
  public string Subject { get; set; }

  public string OtherProp1 {get; set;}
  public string OtherProp2 {get; set;}
  public string OtherProp3 {get; set;}    
}
于 2012-08-15T19:40:21.957 に答える
3

残念ながら、この場合、2 番目のオプションはあまり明確ではありません。これは、Email class.

あなたのメソッドを呼び出すとします。あなたは私にEmailクラスのインスタンスを渡させます。クラス コントラクトに移動すると、7 つのプロパティが見つかります。

また、どのパラメーターが必須で、どのパラメーターがオプションであるかをどのように知ることができますか? ドキュメントから？APIを適切に使用するためにドキュメントを参照する必要がある場合、最もクリーンな設計ではありません。

Email クラスをリファクタリングして、これらすべてのオプション パラメータを削除して呼び出すようにし、サービスの戻り値として使用する必要がある場合は、EmailRequestさらに別のクラスを作成します。EmailResponse

于 2012-08-15T19:27:46.193 に答える
1

OOPの方法で行く方が常に良いです。メールクラスが過剰な場合は、別の解決策を分析して定義してみてください。このような

   public class Email
    {
          //everything needed for service is extracted in another class
          public EmailAddressDetails {get;set}
          //I am not going to use this properties in send email method
          public string OtherProp1 {get; set;}
          public string OtherProp2 {get; set;}
          public string OtherProp3 {get; set;}

      }

このようなサービスを使用します

   public bool SendEmail(EmailAddressDetails email){//My Logic}}
于 2012-08-15T19:18:46.217 に答える
0

両方書いたらどうですか？そして、単に最初のものを持って、2番目を呼び出しますか？

于 2012-08-15T19:12:41.930 に答える
0

オブジェクトをEmail[DataContract] にして、オプション 2 を使用します。1 つのサービス メソッドにそれほど多くのパラメーターは必要ないというのが私の意見です。

于 2012-08-15T19:15:14.550 に答える