4

SQLに一連の条件を使用してクエリを実行するモデルがあります。その結果、モデルは多くのパラメーターを受け入れる必要があります。

this->model_name->method($param1, $param2, ... )

モデル側では、私は通常これを次のように設定します

function method($param1 = NULL, $param2 = NULL, ... )

これらの各パラメーターはオプションであり、ユースケースはアプリによって異なります。だから私の質問は次のとおりです：どの時点で（もしあれば）これらのパラメータを配列を介してメソッドに渡し始めるのは理にかなっていますか？

$params = [
'param1' => 'whatever',
'param2' => 'whatever',
...
]

this->model_name->method($params)

最終的な目標は、コードをクリーンにし、それが問題ない場合をmethod(null, null, null, null, $param)除いて、インスタンスを減らすことだと思います。

4

4 に答える 4

2

ほとんどの回答は配列法を支持してきましたが（一般的に言えば、私も同意します）、悪魔の代弁者を演じて、いくつかの欠点を挙げます。

ドキュメントはあまり明確ではありません

関数/メソッドを文書化するほとんどのメソッドは、その関数のパラメーターを個別にリストします。たとえば、基本的なDocBlockを備えた関数は次のようになります。

/**
 * A function that accepts an array of params
 * @param array $param_array An array of key=>value arguments
 */
function accept_array($param_array = array('key1' => 'first_val', 'key2' => 'second_val')) {

    var_dump($param_array);

}

DocBlockが$param_array、配列全体だけでなく、の個々の部分を直接サポートしていないことに注意してください。対照的に、すべての引数を個別にリストすると、次のようになります。

/**
 * A function that 'normal' params
 * @param string $key1 First argument
 * @param string $key2 Second argument
 */
function accept_normal($key1 = 'first_val', $key2 = 'second_val') {

    echo $key1;
    echo $key2;

}

これは、関数がかなり自己文書化されることを期待する場合にも問題になります。最初の例では、関数自体に期待される引数を実際にリストする必要がないためです。

デフォルト値が期待どおりに機能しない場合があります

「期待どおり」はおそらく少しロードされたフレーズです（そしてこれはおそらくより明白な問題の1つです）が、次のことを取ります：

function accept_array($param_array = array('key1' => 'first_val', 'key2' => 'second_val')) {

    var_dump($param_array);

}

accept_array(array('key2' => 'a_different_val'));

var_dumpにのデフォルト値key1との新しい値が含まれることを期待する人もいるかもしれませんkey2が、配列全体が置き換えられます。つまり、次のように、各関数で各キーのデフォルト値を手動で設定することを忘れないでください。

function accept_array($param_array = array()) {

    if (!isset($param_array['key1'])) { $param_array['key1'] = 'first_val'; }
    if (!isset($param_array['key2'])) { $param_array['key2'] = 'second_val'; }

    var_dump($param_array);

}

accept_array(array('key2' => 'a_different_val'));

自動フィルタリングなし

引数を「通常の」方法でリストすると、組み込みのフィルターセットも提供されます。たとえば、この迅速で汚いユーザー検索を見てください。

/**
 * We want to allow searching for users by user_id or email only!
 * @param array $param_array
 */
function find_user($param_array = array('user_id' => 0, 'email' => '')) {

    foreach ($param_array as $field => $value) {
        $this->db->or_where($field, $value);
    }

    $this->db->get('users');

}

find_user(array('first_name' => 'Joe', 'last_name' => 'Bloggs'));

にいくつかの「受け入れられたキー」タイプの検証を手動で追加しなくても、関数$param_arrayの呼び出しは基本的に好きなフィールドを使用できます。find_user()より単純なバージョンは明らかに次のようになります。

/**
 * We want to allow searching for users by user_id or email only!
 * @param int $user_id
 * @param string $email
 */
function find_user($user_id = 0, $email = '') {

    $this->db->or_where('user_id', $user_id);
    $this->db->or_where('email', $email);

    $this->db->get('users');

}

// No way for me to submit any other fields, they'll just fail when they get to the query
find_user('Joe', 'Bloggs'));

私はこれらのいくつかが少しエントリーレベルであることを受け入れます、そしておそらく私が逃したものはもっとたくさんあります（もっとコメントしてください、そして私はそれらをクレジットで返信にコピーします）、しかしうまくいけば人々に二度考えさせるのに十分です手動の検証や文書化などを考慮せずに、「配列メソッド」を自動的に使用します。

于 2013-03-11T19:32:59.583 に答える
1

パラメータの配列を渡すと、コードを自己文書化するためのより良いオプションが提供されます。

多くのパラメーターを使用すると、次のようなスタイルを使用することがよくあります。 

// do_something_model($enable_option1,$enable_option2,$enable_option3) 
   do_something_model(FALSE,          TRUE,           FALSE)

ここでは、モデルの使用方法を思い出させるために、パラメーター名を含むコメント行を付けています。

このような場合、意味のある名前のキーを持つ配列を使用すると、便利なニーモニックが提供されます。

最近では、より多くのラッパー関数も使用しています。たとえば、基本的なモデルメソッドでテーブルからすべてのデータを取得する場合、このメソッドにはいくつかのオプションがあります。

次に、特定のタスクを実行する新しいメソッドを定義し、正しいオプションを使用してその中の基本的なメソッドを呼び出します。

脚注
私のメソッドに「オプションが多すぎる」場合は、メソッドの目的を再考し、使いやすい2つ以上の特殊なメソッドに分割する方がよいことがわかりました。

于 2013-03-11T16:32:06.570 に答える
0

アレイバージョンもお勧めします。Symfony2もこのパターンを頻繁に使用します。たとえば、テンプレートのレンディング、フォームクラスの作成、一般的なhttp応答の作成などです。考えられるすべてのパラメータを明確に文書化する必要があります。

于 2013-03-11T16:28:15.027 に答える
0

どちらのルートでもかまいませんが、配列を使用すると、メソッドが確実にクリーンに保たれます。パラメータを配列として渡すことは完全に理にかなっています。

于 2013-03-11T16:28:45.700 に答える