選択肢3.基本例外はすでにリモート処理をサポートしているか、それ以外の場合はにはリモーティングを追加しません。
コメント内の「例外」マークのコメントは次のとおりです。テスト作成者が念頭に置いたものではないと思います。
WCFサービスでは、未処理の例外がサービスから伝達されるようにすることができます。 WCFはSOAPフォールトに変換します。SOAPフォールトには、構成に応じて未処理の例外の詳細が含まれる場合と含まれない場合があります。
特定の例外セットを認識し、意図的にSOAPフォールトに変換する方がよいでしょう。たとえば、データベースエンティティで動作するサービスでは、エンティティが見つからないことがあります。新しいエンティティを追加しようとすると重複が発生することがあります。更新の試みによって無効な状態が生じることがありました。このようなサービスでは、NotFoundFault
,DuplicateItemFault
、およびInvalidStateFault
が公開される可能性があります。
サービスは、その内容を定義するデータコントラクトとして3つの障害を定義します
[DataContract]
public class FaultBase {
[DataMember]
public string ErrorMessage {get;set;}
}
[DataContract]
public class NotFoundFault : FaultBase {
[DataMember]
public int EntityId {get;set;}
}
[DataContract]
public class DuplicateItemFault : FaultBase {
[DataMember]
public int EntityId {get;set}
}
[DataContract]
public class InvalidStateFault : FaultBase {
}
あなたは、特定の操作は、このような障害を返すことができることを示すことになる:
[OperationContract]
[FaultContract(typeof(NotFoundFault))]
public Entity GetEntityById(int id)
最後に、あなたが包むかもしれません代わりにWCFが特定の障害を返すようなDALの例外:
try {
return DAL.GetEntity<Entity>(id);
}
catch (DAL.NoSuchEntityException ex)
{
throw new FaultException<NotFoundFault>(
new NotFoundFault {EntityId = ex.Id, ErrorMessage = "Can't find entity"});
}
テストデベロッパーは、別のAppDomainへのリモート処理のために例外をシリアル化するために特別な処理が必要であると考えるようにしていると思います。提供された.NET例外クラスがすべて直列化可能であるため、カスタム例外が適切に実装されていれば、これは当てはまりません。したがって、シリアライズする能力は、基本クラスがすでにシリアライズ可能である必要があるため、カスタム例外を作成する言い訳ではありません。
PS。テストは "C#2.0 Fundamentals"でしたので、WCFの面は考慮できません。 – nightcoder