問題のコードはロボット(CodeSmith)によって書かれており、維持するのは苦痛です。それはクライアント側のWCFのプロキシコードだと、すべてのこれらの行があるすべてのサービスメソッドのために繰り返され、あなたが推測できるとおりメソッド呼び出しの共通機能を追加するにはどうすればよいですか?
public AddressProgramTemplate GetById(System.Int32 _id) {
try {
return Service.GetById(_id);
} catch (FaultException<ErrorInfo> ex) {
throw new ProxyServerBusinessException(ex.Detail);
} catch (FaultException) {
throw new ProxyServerBusinessException(null);
} catch (EndpointNotFoundException ex) {
throw new ProxyServerTechnicalException<EndpointNotFoundException>(ex);
} catch (CommunicationObjectFaultedException ex) {
throw new ProxyServerTechnicalException<CommunicationObjectFaultedException>(ex);
} catch (CommunicationException ex) {
throw new ProxyServerTechnicalException<CommunicationException>(ex);
} catch (ObjectDisposedException ex) {
throw new ProxyServerTechnicalException<ObjectDisposedException>(ex);
} catch (TimeoutException ex) {
throw new ProxyServerTechnicalException<TimeoutException>(ex);
}
}
(その多くがあります):これは、と少し似ています。ロボットにとっては、私にとっては悲しみなので、私はそれをリファクタリングし始めました。まず、例外ロジックや取り扱いには、Microsoftエンタープライズライブラリに委任されており、共通のコードは、基本クラスに移行:
public TResult WrapServiceMethod<TResult>(Func<TResult> serviceMethod) {
TResult result = default(TResult);
try {
result = serviceMethod();
} catch (Exception ex) {
bool rethrow = ExceptionManager.HandleException(ex, ExceptionPolicyNames.ClientRequestPolicy);
if (rethrow) throw;
}
return result;
}
をこれまでのところは良い、醜いのtry/catchパイルは、きちんとしたワンライナー次のようになります。
return WrapServiceMethod<AddressProgramTemplate>(() => Service.GetById(_id));
少しの努力と無効な方法も同様にカバーされます。 「匿名メソッド、ラムダ式、またはクエリ式内refまたはパラメーター 『endDateに』外には使用できません」で
public void GetPeriod(AddressProgram program, out DateTime startDate, out DateTime endDate){
WrapServiceMethod(() => Service.GetPeriod(program, out startDate, out endDate));
}
結果と私はwhyを理解する:サービスコールがout
パラメータを使用するときに問題が来ます。私は理想的に持っていると思い何
)が(例えばながら、()または使用などのカスタムオペレータブロックを定義する機能ですので、私は「
wrapexception { ... }
を書いて、その後ずっと幸せに暮らすが、私はドンができこのトリックは.NETで可能だと思います。 out
パラメータを使用せずにすべてのサービスメソッドを書き直すことが最後の手段であると仮定して、他のオプションはありますか?
有望に見える - そのロボットは、ソースコードの代わりにコンパイルされたアセンブリを変更します。確かに維持する方がずっと簡単です。重大なパフォーマンス上の欠点はありますか? –
すべてのAOPライブラリがポストコンパイルではないことを指摘しておきます。 PostSharpはありますが、コンパイルされたアセンブリは変更されません。 dodgyの面を書かない限り、パフォーマンスに影響を与えるべきではありません。いつものように、プロフィールと比較して確かめてください。 Spring.NETは、プロキシオブジェクトを使用してAOPを実装する方法としてメソッドインターセプタを作成します。 –
私はおそらくMicrosoft Enterprise LibraryからPolicyInjectionに行くのは、Microsoft(販売しやすい)であり、すでにプロジェクトで使用されている(販売しやすい)ためです。 –