2

最近、このテーマについていくつか質問をしましたが、何とかしてやらなければならないことを絞り込むことができたと思います。

Railsアプリでいくつかの「メトリクス」(アプリケーションのパフォーマンスに関連するメトリクスと混同しないように引用符で囲みます。これらはアプリケーションデータに基づいて生成されるメトリクスです)を作成しようとしています。基本的に、私の見解では、次のようなものを使用できるようにしたいと思います。

@metric(@customer,'total_profit','01-01-2011','31-12-2011').result

これにより、特定の顧客の2011年の総利益が得られます。

もちろん、カスタムメソッドを使用してメトリックモデルを作成することはできますがresult、カスタムメトリック(total_profit、total_revenueなど)を簡単に拡張できるように作成するための最善の方法について混乱しています。カスタムメトリックは、ユーザーごとに追加できます。

operand私の最初の考えは、各カスタムメトリックの式を、、operationおよびモデルを含む構造に格納しようとすることでしたoperation_typeが、これはすぐに非常に面倒で冗長になり、各メトリックを追加するという点で非常に困難でした。

私の考えでは、各メトリックを保持するカスタムメトリックヘルパーメソッドを作成できる可能性があります(したがって、各メトリックをハードコーディングして、各メソッドに変数を渡すことができます)が、これはどの程度拡張可能でしょうか?このオプションは、あまりレール風ではないようです。

誰かがこの問題に取り組むためのより良い代替案を提案できますか?

編集:以下の答えは、物事を非常に単純に保つという点で良いものです-私はそれがevalを使用しているので危険に満ちているかもしれないと心配していますが(したがって、ユーザーコードを使用する見込みはありません)。constantizeこれを行うための別のオプションはありますか(オペランドなどがとの組み合わせを使用してチャンクに分割された以前のオプションget_instance_variable-文字列の実行をより安全にするためにこれらを使用できる方法はありますか)?

4

1 に答える 1

0

この質問は、 Rails - スケーラブルな計算モデルでの議論で大部分が答えられました。

これに遭遇した人にとって、解決策は基本的に操作が常に 2 つのオペランドを持つようにすることですが、オペランドは属性または以前の計算の結果 (つまり、メトリック自体である可能性があります) のいずれかである可能性があり、したがって、スケーラビリティが高い。これにより、何かを評価する必要がなくなり、これに伴う潜在的なセキュリティ ホールが回避されます。

于 2012-07-10T09:26:57.197 に答える