2015-10-26 23 views
5

私は、そのAPIを通じて別のソフトウェアのアドインを作成しています。 APIによって返されるクラスは、ネイティブソフトウェアとAPIを介してのみアクセスできます。だから私は自分のスタンドアロンのPOCO/DTOオブジェクトをAPIクラスにマップしています。私はネイティブファイルを読み込んで、他の場所で盗むことができるこれらのPOCOオブジェクトのコレクションを返す機能に取り組んでいます。現在、私はJSON.NETを使ってこれらのクラスをJSONにシリアル化しています。私は私のDTOにネイティブ「人」を読むためにこの戻り値を含むエラーを含めるためのデザインパターン

public class MyPersonDTO 
{ 
    public string Name {get; set;} 
    public string Age {get; set;} 
    public string Address {get; set;}  
} 

..andこのような方法のようにDTOを持っているかもしれません例えば

public static class MyDocReader 
{ 
    public static IList<MyPersonDTO> GetPersons(NativeDocument doc) 
    { 
     //Code to read Persons from doc and return MyPersonDTOs 
    } 
} 

は、私はユニットテストのセットアップを持つオブジェクトテストファイルを使用していますが、エクスポートを他のファイルで実行すると予期しない問題が発生します。ときどきネイティブオブジェクトに予期しない値があるか、APIにバグがあり、理由がない場合に例外がスローされます。

現在、「例外」が発生したときに例外が記録され、エクスポートが失敗します。しかし、私はできることを輸出し、どこかでエラーを記録することに決めました。

最も簡単なオプションは、例外をログして飲み込んで、できることを返すことですが、問題が発生したときに私の呼び出しコードが知る方法はありません。

私が検討しているオプションは、エラーの辞書を別の出力パラメータとして返すことです。キーは読み取ることができなかったプロパティを識別し、値には例外/エラーの詳細が含まれます。

public static class MyDocReader 
{ 
    public static IList<MyPersonDTO> persons GetPersons(NativeDocument doc, out IDictionary<string, string> errors) 
    { 
     //Code to read persons from doc 
    } 
} 

また、返すオブジェクト自体にエラーを格納することも考えていました。これはオブジェクトのサイズを膨らませますが、オブジェクトに直接エラーを格納するという利点があります。したがって、後で誰かのエクスポートがエラーを生成する場合、私は自分のコンピュータ上で正しいログファイルを追跡することを心配する必要はありません。

public class MyPersonDTO 
{ 
    public string Name {get; set;} 
    public string Age {get; set;} 
    public string Address {get; set;} 

    public IDictionary<string, string> Errors {get; set;} 
} 

これは通常どのように処理されますか?私が考慮していない戻り値と共にエラーを報告する別のオプションがありますか?

+0

実装に依存して、Martin Fowlerは最後のオプションが最も有効であると考えます。あなたが何かがうまくいかないときに例外をスローする例外の方法もあります。 – Fals

+0

マーティンがこれについて語っているブログ投稿やプレゼンテーションへのリンクがありますか? –

+0

投稿のリンク先:http://martinfowler.com/articles/replaceThrowWithNotification.html – Fals

答えて

4

エンティティの一部としてエラーを返す代わりに、結果を返信または応答メッセージにラップすることができます。エラーは、エンティティの代わりに応答メッセージの一部となる可能性があります。

この利点は、エンティティがきれいをしていることである

欠点は、怒らエンティティ/属性に戻ってエラーをマップするために困難になるということです。

エンティティのバッチを送信する場合、この欠点は大きな問題になります。 APIがより多くの単一エンティティ指向の場合、それほど重要ではありません。

+0

これは良い選択ですが、残念ながら私はめったに単一のオブジェクトで作業していません。最も一般的な使用例は、2つの別々のファイルからの多数のオブジェクトエクスポートを比較することです。私はまた、ほとんどの場合、返されたオブジェクトをJSONにシリアル化し、そのJSONを後で扱います。したがって、エラーを個別に格納することは問題になります。 –

+0

私は彼が 'パブリッククラスParseResponse'を返すという意味だと信じています。パブリッククラスParseResponse {public IList Persons {get; set;} public IList 例外{get; set;}}'あなたはreturn.Personsとステータス/リターンコードのデータは使用できません。 –

+0

はい、そうです –

1

原則として、(回復できない)APIで何か問題が生じた場合、呼び出しコードは例外が発生したことを認識している必要があります。だから、それに対処する戦略を立てることができます。

そのため、私の心は同じ哲学に影響されることになるのアプローチ -

1>は、独自の例外がIncompleteReadExceptionを言うことができます定義します。 この例外は、例外が発生するまで読み取られたレコードを格納するプロパティーIList<MyPersonDTO>を持ちます。読み取り中に例外が発生した場合

public class IncompleteReadException : Exception 
{ 
    IList<MyPersonDTO> RecordsRead { get; private set; }  

    public IncompleteReadException(string message, IList<MyPersonDTO> recordsRead, Exception innerException) : base(message,innerException) 
    { 
     this.RecordsRead = recordsRead; 
    } 
} 

2>は、あなたが持っている、元の例外をキャッチこれは、呼び出し元のコード(アプリケーションコード)を許可しますIncompleteReadException

この1つの&スローで元の例外をラップすることができます不完全なデータが読み込まれたときの状況に対処する戦略。

関連する問題