菜菜鳥Zend Framework 2不完全学習落書き(十五)--高級配置テクニック

高度な構成テクニック
Zend Framework 2アプリケーションの構成は、次の手順で行います.

初期構成では、ApplicationインスタンスとModuleManagerとServiceManagerを使用するシードを使用します.このチュートリアルでは、この構成をシステム構成(System Configuration)

と呼びます.

モジュール呼び出しがある場合、ModuleManagerのコンフィギュレーションおよびマージ.このチュートリアルでは、この構成をアプリケーション構成(Application Configuration)

と呼びます.

すべてのモジュールから構成を集約すると、ConfigListenerはまた、指定されたディレクトリにグローバルアプリケーション構成(典型的なディレクトリはconfig/autoload/)

をマージする.
このチュートリアルでは、適切な順序とどのように制約するかに着目します.
一、システム構成(System Configuration)
モジュールのマウントを開始します.有効なモジュールとどこにあるかをApplicationインスタンスに伝えなければなりません.デフォルトのモジュールListener(アプリケーションの構成場所、ファイルのマウント方法、連結構成のキャッシュの有無など)に任意の情報を入力し、ServiceManagerの種まきを行います.このチュートリアルでは、この構成をシステム構成(System Configuration)と呼びます.
アプリケーション・スケルトン(またはアプリケーション・フレームワーク)を使用する場合、システム構成(System Configuration)はconfig/application.config.phpにデフォルト設定されます.次のコードに似ています.

<?php
return array(
    // This should be an array of module namespaces used in the application.
    'modules' => array(
        'Application',
    ),

    // These are various options for the listeners attached to the ModuleManager
    'module_listener_options' => array(
        // This should be an array of paths in which modules reside.
        // If a string key is provided, the listener will consider that a module
        // namespace, the value of that key the specific path to that module's
        // Module class.
        'module_paths' => array(
            './module',
            './vendor',
        ),

        // An array of paths from which to glob configuration files after
        // modules are loaded. These effectively overide configuration
        // provided by modules themselves. Paths may use GLOB_BRACE notation.
        'config_glob_paths' => array(
            'config/autoload/{,*.}{global,local}.php',
        ),

        // Whether or not to enable a configuration cache.
        // If enabled, the merged configuration will be cached and used in
        // subsequent requests.
        //'config_cache_enabled' => $booleanValue,

        // The key used to create the configuration cache file name.
        //'config_cache_key' => $stringKey,

        // Whether or not to enable a module class map cache.
        // If enabled, creates a module class map cache which will be used
        // by in future requests, to reduce the autoloading process.
        //'module_map_cache_enabled' => $booleanValue,

        // The key used to create the class map cache file name.
        //'module_map_cache_key' => $stringKey,

        // The path in which to cache merged configuration.
        //'cache_dir' => $stringPath,

        // Whether or not to enable modules dependency checking.
        // Enabled by default, prevents usage of modules that depend on other modules
        // that weren't loaded.
        // 'check_dependencies' => true,
    ),

    // Used to create an own service manager. May contain one or more child arrays.
    //'service_listener_options' => array(
    //     array(
    //         'service_manager' => $stringServiceManagerName,
    //         'config_key'      => $stringConfigKey,
    //         'interface'       => $stringOptionalInterface,
    //         'method'          => $stringRequiredMethodName,
    //     ),
    // )

   // Initial configuration with which to seed the ServiceManager.
   // Should be compatible with Zend\ServiceManager\Config.
   // 'service_manager' => array(),
);

システム構成MVCに関する点滴は、システムの前に実行され、準備されています.構成は通常、プレゼンテーションであり、かなりコンパクトです.
また、すぐに使用されるシステム構成は、他の構成を統合していません.つまり、他のモジュールで上書きすることはできません.
これは、特定の環境でのシステム構成をどのように提供するかという最初のテクニックに導きます.
二、特定環境システムの構成
環境ベースのモジュールを変更するとどうなりますか?または、環境ベースでキャッシュを有効にするとどうなりますか?
そのため、アプリケーションフレームワークで提供されているデフォルトのシステム構成はPHPを使用しています.PHPを使用してサポートされるのは、プログラミングによって制御されるという意味です.
例として、次のようにします.

開発段階のみZendDeveloperToolsモジュール

を使用する必要があります.

本番でのみ構成キャッシュ

が必要です.
以上の要件を満たすには、Webサーバの構成に環境変数を設定し、ApacheにAPP_を設定します.ENVかシステムレベルのapacheかconfファイル、http.confファイルに次のようなコマンドを入力するか、仮想ホストで定義しても入力できます.htaccessファイル

SetEnv "APP_ENV" "development"

他のWebサーバの場合は、Webサーバドキュメントを参照して環境変数の設定方法を決定します.
問題を簡略化するために、環境変数が存在しない場合、環境は「本番」であると仮定します.
私たちは以下のコードに従ってconfig/applicationを修正します.config.php

<?php
$env = getenv('APP_ENV') ?: 'production';

// Use the $env value to determine which modules to load
$modules = array(
    'Application',
);
if ($env == 'development') {
    $modules[] = 'ZendDeveloperTools';
}

return array(
    'modules' => $modules,

    'module_listener_options' => array(
        'module_paths' => array(
            './module',
            './vendor',
        ),

        'config_glob_paths' => array(
            'config/autoload/{,*.}{global,local}.php',
        ),

        // Use the $env value to determine the state of the flag
        'config_cache_enabled' => ($env == 'production'),

        'config_cache_key' => 'app_config',

        // Use the $env value to determine the state of the flag
        'module_map_cache_enabled' => ($env == 'production'),

        'module_map_cache_key' => 'module_map',

        'cache_dir' => 'data/config/',

        // Use the $env value to determine the state of the flag
        'check_dependencies' => ($env != 'production'),
    ),
);

この方法は、システムレベルの設定を変更する柔軟性をもたらします.
ただし、環境ベースでアプリケーション固有の設定(システム構成ではない)を変更するにはどうすればいいですか?
三、特定環境アプリケーションの構成
データベース・アダプタ、log書き込み、キャッシュ・アダプタ、環境ベースのものなど、アプリケーションの構成を変更して呼び出す場合があります.これらのサービスマネージャの代表的な管理は、モジュールで定義される場合があります.ZendModuleManagerListenerConfigListenerを使用してアプリケーション・レベルで書き換えることができます.システム構成(System Configuration)で指定したグローバル・パス-前の例のmodule_listener_options.config_glob_pathsキーワードを使用します.
デフォルトはconfig/autoload/{,*.}です.{global,local}.php.これはconfig/autoloadディレクトリで以下の順序でアプリケーション構成(Application Configuration)を検索するという意味です.

global.php

*.global.php

local.php

*.local.php

これにより、グローバルプロファイルでアプリケーション・レベルのデフォルト値を定義し、バージョン管理システムにコミットし、特定の環境でローカルプロファイルでバージョン管理を無視する値を書き換えることができます.
これは、開発環境に対して予期せぬ導入を心配することなく、交互の構成を指定できる非常に良い開発ソリューションです.
しかし、「テスト」や「表示」などの環境がたくさんある場合は、それぞれ独自の書き換えがありますか?
もう一度、アプリケーション環境変数を使用します.次のシステム構成のグローバルパスを少し変更できます.

'config_glob_paths' => array(
    sprintf('config/autoload/{,*.}{global,%s,local}.php', $env)
),

以上のコードを使用すると、環境ごとにアプリケーションプロファイルを追加定義できます.また、これらの構成は、対応する環境が検出された場合にのみ呼び出されます.
一例として、次のプロファイル構造ツリーを考えてみましょう.

config/
    autoload/
        global.php
        local.php
        users.development.php
        users.testing.php
        users.local.php

$envがtestingの場合、次のファイルは順番にマージされます.

global.php
users.testing.php
local.php
users.local.php

注意:users.development.phpは呼び出されていません.グローバルモードに一致していないからです.
また、順番に呼び出されるため、他の値を上書きする値を予測できます.これにより、後のデバッグで選択的に上書きできます.
注意:
config/autoload/ディレクトリのファイルは、モジュール構成後にマージされます.詳細は、次の段落を参照してください.詳細には説明するが、アプリケーション構成(Application Configuration)のグローバルパスを設定することは、システム構成(System Configuration)における(config/application.config.php)
四、モジュール配置
モジュールの役割の1つは、アプリケーションに独自の構成を提供することです.モジュールには2つの一般的なメカニズムがあります.
まず、ZendModuleManagerFeatureConfigProviderInterfaceで実装するか、getConfig()メソッドでモジュールの構成を返します.デフォルトでは、getConfig()メソッドを推奨します.

public function getConfig()
{
    return include __DIR__ . '/config/module.config.php';
}

module.config.phpはPHP配列を返します.
第二に、モジュールは、指定されたサービスマネージャまたはプラグインマネージャの構成に関連する多くのインタフェースおよび/または方法を実装することができる.例:
インタフェース名
メソッド名
ControllerPluginProviderInterface
getControllerPluginConfig()
ControllerProviderInterface
getControllerConfig()
FilterProviderInterface
getFilterConfig()
FormElementProviderInterface
getFormElementConfig()
HydratorProviderInterface
getHydratorConfig()
InputFilterProviderInterface
getInputFilterConfig()
RouteProviderInterface
getRouteConfig()
SerializerProviderInterface
getSerializerConfig()
ServiceProviderInterface
getServiceConfig()
ValidatorProviderInterface
getValidatorConfig()
ViewHelperProviderInterface
getViewHelperConfig()
すべてのインタフェースリストはZendModuleManagerFeatureネーミングスペースにあり、それぞれがサービスマネージャの構成配列を返します.「デフォルトのサービス管理」に記載されています.
モジュールプロファイルにサービス構成が含まれる可能性があることを考慮すると、どちらが優先ですか?
連結の順序は次のとおりです.

getConfig()が返す構成

モジュールクラスにおいて種々のサービス構成方法によって返される構成

.
つまり、さまざまなサービス構成方法を優先します.また、メソッドから返される構成はキャッシュされません.なぜなら、閉パッケージまたはファクトリインスタンスを頻繁に使用してモジュールクラスから構成を返すわけではありません.信頼性の高いキャッシュ構成はできません.
注意:
閉パッケージを定義したり、ファクトリ・モードのコールバック・インタフェースを定義したり、抽象ファクトリを定義したり、初期化したりする必要がある場合は、キャッシュの問題を予防し、他のフォーマットで自分のプロファイルを書くこともできます.
五、連結構成ワークフロー
このチュートリアルを終了する前に、構成の定義とマージ方法について振り返ってみましょう.
システム構成(System Configuration)-config/application.config.phpで定義-マージしません-プログラミングで操作できます.許可:

計算値に基づいてタグ

を変更する.

計算値に基づいて構成グローバルパス

を変更する.

の構成がApplicationインタフェースに渡され、ModuleManagerがシステム

を順次初期化する.
≪アプリケーション構成｜Application Configuration｜Eas≫-ModuleManagerは、定義された順序で各モジュール・クラスにループ・アクセスします.
システムコンフィギュレーション(System Configuration)で-モジュールクラスで定義されたサービスコンフィギュレーションは集約-Module::getConfig()で返されるコンフィギュレーションは集約

サービスコンフィギュレーションのconfig_glob_paths設定から見つかったファイルがマージされます.マージの順序は、グローバルパスの順序に従います.

統合後の構成は、最終的にServiceManager

に渡されます.
未完待機、ありがとう・・・