1

私のアプリケーションには定数があります：

define('APP_PATH', WEB_ROOT . APP_DIR);
define('LIBS_PATH', APP_PATH . LIBS_DIR);
define('MODELS_PATH', APP_PATH . MODELS_DIR);
define('VIEWS_PATH', APP_PATH . VIEWS_DIR);
define('CONTROLLERS_PATH', APP_PATH . CONTROLLERS_DIR);
etc...

アプリケーションが起動すると変更されることはなく、任意のクラス/メソッド内から簡単にアクセスできるためです。

私は他の設定を含む構成ファイルも持っています。これは$configオブジェクトにインポートされ、アプリケーションを渡して次のように取得します。

$this->config->setting('some.setting');

アプリケーションの最後または途中で構成値を変更する必要がなかったので、コード内で簡単にアクセスできるように、それらを定数として定義する方が簡単ではないでしょうか?

設定を静的に取得したくありません。

Config::setting('some.setting');

Config私はいくつかのPHPフレームワークのコードを見てきましたが、それらはすべてパスを定数として定義していますが、コード全体でこれらの構成設定を変更することは決してないことがわかりますが、何らかのクラスに他の構成設定があります（私は何万ものすべての行を読んだわけではないので）、これらのフレームワークの多くは、さまざまなクラスのメソッド内からあらゆる種類のメソッドへの静的呼び出しを行うのが好きなようで、人々はそれらが優れたフレームワークであると言いますが、私は読んで経験しましたクラス/メソッド内の静的呼び出しに関しては、良いよりも悪いです。

構成設定をどうするのが最善だと思いますか? 職業はなんですか？

4

2 に答える 2

0

構成オブジェクトで設定をラップすると、カプセル化が提供され、より優れた共存が可能になります。

たとえば、データベースにアクセスするためのフレームワークがあるとします。これにグローバル設定を使用すると、1 つのプログラムで複数のデータベースに簡単にアクセスできなくなります。設定をオブジェクトに入れると、対応するデータベースに特定の構成オブジェクトを使用できます。

于 2013-01-01T15:19:37.767 に答える
0

定数をオブジェクトにラップすると、コードの移植性が向上します。

このようにして、たとえばファイルからアプリケーションのブートストラップ時に定数をロードできるため、任意の数のアプリでそれぞれ異なる構成ファイルを使用してコードを再利用できます。

別の意味では、クラスからの読み込みはファサードとして機能します。設定をファイルからデータベースに移動したり、ハードコーディングしたりしても、アプリケーション全体は気付かないでしょう。

defineもちろん、非常に小さなプロジェクトでも使用できます。

于 2013-01-01T13:40:19.287 に答える