以下のアプローチが、複数の環境でカスタム構成パラメーターをキャプチャするのにどれほど悪いかを知りたいです。これは、数層の深さで編成する必要がある非常に大きな構成パラメーターがある場合に対処することを目的としています。
次の機能が必要です: - 構成パラメータの設定は非常にシンプルで、コピー/貼り付けが簡単である必要があります - 構成パラメータへのアクセスは簡潔である必要があります - 柔軟性のためにプログラムである必要があり、yaml はありません (確信がない限り) - 環境ごとの構成は必要ありません必須、正常なデフォルト (この場合は :base 構成) にフォールバックする必要があります - 構成オブジェクトの初期化は簡潔にする必要があります - 環境の詳細は非表示にする必要があります
この実装の欠点: - eval は悪か? この場合、 eval は本当に悪いのでしょうか? ユーザーは値を制御しません。値はすべてソースにハードコードされています。-最速ではありませんが、私の場合は問題ではありません-ハッシュの初期化は奇妙です-「get」呼び出しもちょっと変です
これは、大量のパラメーターを持つ可能性のあるファイルを処理する堅牢な方法が必要だったために作成されました。これらのパラメーターは環境によって異なる可能性があるため、(環境ごとに) 基本値を簡単にオーバーライドできることが重要です。
これらのパラメーターは、それらが呼び出されるモデルと密接に結合する必要があるため、初期化子とグローバルはオプションではありません。
誰かがこれらの目標をはるかにエレガントな方法で達成するためのより良い方法を持っているなら、私は聞きたいです. このコードは良い偶像的な設計ではないので、強力な oop アプローチなど、他のアイデアを得たいと思っています。
class Paramz
def initialize(params)
@env = :development # Rails.env.to_sym
@params = params
end
def get(values)
eval_hash(values.split("."))
end
protected
def eval_hash(values)
new_val = String.new
values.map { |v| new_val = new_val + "[:#{v}]" }
base, env = eval("@params[:base]" + new_val), eval("@params[@env]" + new_val)
return env != {} ? env : base
end
end
p = Hash.new{ |h,k| h[k] = Hash.new(&h.default_proc) }
# file config
p[:base][:file][:path] = "/opt/files"
p[:qa][:file][:path] = "c:\\files\\"
p[:production][:file][:path] = "/opt/projects/final"
params = Paramz.new(p)
# env = :base
puts params.get("file.path")
# >> "/opt/files" # returns :base config
# env = :development
# puts params.get("file.path")
# >> "/opt/files" # no :development config, falls back on :base
# env = :production
# puts params.get("file.path")
# >> "/opt/projects/final" # return :production config