4

SOAPを介してテーブルを公開できるダウンストリームシステム、ERPシステムがあります。通常、公開する Web サービスには、Create、Update、および Delete メソッドがあります。次に、非同期メソッドを含む svcutil を使用して、側でプロキシを生成します。最後に、他のシステムとやり取りできるように、この前に ACL を配置します。

また、重要な不変条件も発見しました。アイテムの原価計算情報は、ERP システム自体以外では更新できません。しかし、本当にばかげた API は、消費者がこれを行うことを可能にします。

これを回避するための私の考えは、WCF プロキシをサブクラス化し、その throw を更新するための明示的な実装を用意することNotSupportedExceptionです。いいえ、これは開発者が独自のプロキシを生成して実行することを止めるものではありません。しかし、少なくとも、ACL を通過するときに発生しないことを保証できます。

    Update_Result Item_Port.Update(Update request)
    {
        throw new NotSupportedException();
    }

非同期メソッドの場合、次のいずれかを行うことができます

    Task<Update_Result> Item_Port.UpdateAsync(Update request)
    {
        throw new NotSupportedException();
    }

また

    Task<Update_Result> Item_Port.UpdateAsync(Update request)
    {
        return Task.Factory.StartNew<Update_Result>(() =>
        {
            throw new NotSupportedException();
        });
    }

非同期の観点から、どちらがより「正しいですか?」

4

1 に答える 1

5

2 つは異なる動作をします。

最初のケースでは、この API の呼び出し元は、NotSupportedExceptionこのメソッドを呼び出すとすぐに を取得します。

2 番目のケースでは、発信者はフォルトを受け取りますTask<T>(または、発信後すぐにフォルトになります)。これにより、タスクの継続中、またはタスクの値が ( 経由でtask.Result) フェッチされたときに例外が発生します。

あなたの目標を考えると、私は個人的に最初の方法を使用します。これにより、オーバーヘッドが少なくなり (タスクを作成していないため)、何かがおかしいことが呼び出しサイトにすぐにわかります。コンパイル時エラーほど良くはありませんが、タスクが「起動して忘れる」方法で呼び出された場合でもスローされるため、デバッグ中に見逃される可能性ははるかに低くなります。

于 2013-04-22T23:59:26.437 に答える