0

application/config/config.php にカスタム構成項目があります。

私のカスタム設定項目のサンプル:

$config['website_title'] = 'ABC Website'; //Assume website title is fixed
.
.
.
etc

これで、アプリケーションのどこでも呼び出す$this->config->item('website_title')ことができます。ただし、プロジェクト内に複数の $this->config->item('website_title') がある可能性があるため、十分に効率的ではありません。私は次の解決策を思いつきました：

1.ヘルパー内に、構成アイテムを次のように返す関数を作成します。

public function website_title() {

  return $this->config->item('website_title');

}

2.これで、website_title() を好きなだけ呼び出すことができます。

これは良い解決策ですか？欠点はありますか？

注：グローバル変数の使用を避けようとしましたが、試してみたところ、未定義の変数などの多くの不要な問題に直面し、驚いた!

4

2 に答える 2

0

「効率的」とはどういう意味ですか？実行時の効率は？コーディング効率？明快さ？

実行時の効率の観点から、Truthの使用に関する提案は、おそらく最も単純で最良です。ただし、厳密なクラス/オブジェクト実装を使用してコーディングすることを好みます。実際には、定義は単なるグローバル定数です。

スクリプトの大部分をプロファイリングすると、構成参照をコーディングしてもランタイムに重要な影響を与えないことがわかります。そのため、毎回コーディングを単純化して明確にすることをお勧めします。

1つのアプローチは、シングルトンクラスを使用し（これを行うためのチュートリアルがたくさんあります）、魔法のメソッド__get()を使用して、パラメーターアクセスを動的にオーバーロードできるようにすることです。これは、これらのプロパティメソッドがオブジェクト（非静的）パラメータ参照でのみ機能するため、単一のクラスを使用する必要があると私が感じる1つのケースです。したがって、次のように簡単に使用できます。

$cfg = Configuration::get();
...
...   $cfg->someConfigParam ...    // to refer to a config parameter
...
...   /* or even */ ... Configuration::get()->someOtherParameter ...

上記$cfgの例では、基本的にオブジェクトハンドルを格納しているため、これを行うのに実行時のコストはかかりません。必要がない場合は、構成アイテムを参照する各関数またはクラスコンストラクターの先頭にこのステートメントを配置できます。Configuration::get()->someOtherParameter型呼び出しでコードを散らかします。

Configuration::__get()アクセス関数とクラスコンストラクターは、個々のパラメーターのキャッシュとアクセスのすべての複雑さを処理できます。これは、構成のソースもカプセル化することも意味します。アプリケーション固有のD/B構成テーブル。1つ以上の構成ファイル、...; CookieやURIパラメータも（適切な検証を含める限り）。

個人的には、マジックメソッドを使用してオーバーロードすることはお勧めしません__set()。IMO、構成パラメーターのオーバーライドまたは設定は、明示的なアクションである必要があるためです。$cfg->setConfigItem( 'someValue', TRUE );

アイデアが必要な場合は、configクラスのドキュメントへのリンクを次に示します。

于 2012-07-08T15:26:53.483 に答える
0

私はかつてプログラマーにこの種の質問をしました。私は非常に良い答えを得ました。単に定数を使用してください。

いえWEBSITE_TITLE

于 2012-07-08T07:10:22.003 に答える