あなたは何を選択しますか、わずかなパフォーマンスヒットか、さらに複雑さを増しますか？

Question

私たちは、オブジェクトに対して検証アサーションを行うための検証フレームワーク（私たち自身を調理したもの）を使用しています。

string Validation<T,U>(T obj, Func<T,U> selector, Validations.IsNotNull, 
         string failureMessage) 
     { 
      var propertyToBeValidated = selector(obj); 
      // Do validation here, if it fails, return failure message 
     } 

これに伴う問題は、次のとおりです。

• メッセージが必須です。セレクタを見ると意味のあるメッセージを自動的に生成することはできません。

他のオプションは、上記にメソッドのシグネチャを変更することです。この場合、エラーメッセージはオプションであり、我々は式ツリーからプロパティ名を取得することができます

string Validation<T,U>(T obj, Expression<Func<T,U>> selector, 
         Validations.IsNotNull, string failureMessage = null) 

。

しかしセレクタが呼び出される前にExpression.Compileが必要で、3桁の処理が遅くなります。今のところ、メッセージは必須ですが、検証がどこか別の場所にあるので、リファクタリングでも検証メッセージを変更する必要があります。

あなたは何を示唆している：

• 変更署名や表現を受け入れます。必要に応じてコンパイルされた式をキャッシュし、メッセージを自動生成します。メッセージが提供されていますが、それを代わりに使用してください。
• テストカバレッジが優れているため、手作業でメッセージを変更することは許容されるオーバーヘッドです。署名をそのまま残して、複雑さとパフォーマンスの増加を避けます。

編集：この検証フレームワークは、複数のレイヤにわたって使用されています。入力パラメータを検証するoutコントローラ、着信要求を検証するサービス、およびいくつかの操作の後でオブジェクトの状態を検証するための統合テストで使用します。 expression.Compileのコストは、これらのコストの一部と比較して重要ではありませんが、データベースベースのアクセスなどと比較して重要ではありません。

Answer 1

我々は、私たちにとっては、式を使うのが最も理にかなっていると結論づけました。 DBコールとWSコールのオーバヘッドはこれよりはるかに大きかった。

Answer 2

これをdbコールと比較すると、リンゴとオレンジを比較すると思います。また、このコードが複数回呼び出されるオブジェクトごとに、パラメータ、プライベートメンバ、およびこのタイプのオブジェクトがforループで作成されるように装飾されたクラスを想像してみてください。なぜなら、ジェネリックでコーディングをしたり、式などをコンパイルしたりしていないからです。しかし、あなたがやっていることは、検証されたものになることを推測しようとすることです。

は個人的に、私はなぜあなたを行う

Answer 3

...、どのように二つの別々の方法を提供する可能性についてのメッセージが供給されず、十分に文書警告をサポート（多型がある）、それはより良い必須のメッセージを維持することだと思います選択する必要がありますか？あなただけのオーバーロードの両方

string Validation<T,U>(T obj, Func<T,U> selector, Validations.IsNotNull, 
         string failureMessage) 

と

string Validation<T,U>(T obj, Expression<Func<T,U>> selector, 
          Validations.IsNotNull) 

を持つことができます。そうすれば、メッセージがなくてコンパイルされたラムダをキャッシュできないときにのみ、perfヒットします。