Zend Frameworkを使用して柔軟なベースアプリケーションを作成する

Question

Zend Frameworkを利用した電子商取引プラットフォームを開発しています。同じコードベースを使用して、アプリケーションのいくつかのインスタンスを起動して実行しています。設定の設定は、さまざまな店を区別するために使用されます。

私たちが直面している課題は、一般的なプラットフォームをそのまま維持し、上に概説した構成アプローチを使用するのではなく、拡張することです。一般的なプラットフォーム（または基本アプリケーション）には、共通のコントローラ、モデル、およびビューが含まれている必要があります。特定のインスタンスに固有のカスタム機能（コントローラー、モデル、およびビュー）は、別の拡張機能に組み込まれ、コア・プラットフォームにプラグインされます。このようにして、共有されたコードベースはきれいに保たれ、肥大化することはありません。

誰もこのようなアプローチの経験がありますか？周りにベストプラクティスがありますか？

どのポインタも大変ありがとうございます。

Answer 1

私たちはあなたのプラットフォームに似たサウンドのサービスアプリケーションとしてソフトウェアを運用しています。私たちのケースでは、すべてのインスタンスデータがインスタンスのデータベースに保存されています。

カスタム機能（コード）を扱う場合、完全に注文されていれば、カスタムコードをモジュール化して顧客の一意の識別子で参照され、オンデマンドでコードをロードできるコンテナにパッケージ化することが理にかなっていると思います。これはモジュールでは簡単ですが、個々のコントローラーやアクションが必要な場合は明らかに複雑になります。

システムによっては、機能を注入できる独自のイベント/コールバックシステムが組み込まれていますが、これはパブリックAPIで一般的です。

Answer 2

編集：私は様々なコメントに気づいていませんでした。つまり、カスタマイズされたコードは1つのパッケージには含まれておらず、機能が追加され、上書きされません。

ここで問題となるのは、コードが何も上書きされず、機能を追加するということです。おそらく、クラス名を持つ設定ファイルを読むプラグインシステムの何らかの形を見ているでしょう。これらのクラスは各プラグインに関する情報を提供します（つまり、UIでタブを使用する場合は、そのタブの名前のプロパティがあります）。

実際には、実装ごとにどのような機能が異なるかによって異なります。高水準のソリューションを提供するために、より多くの情報を入手することが役立つかもしれません。

私がPHPオートロードを使用する方法（How does OOP manage to 'include' classes stored in different files参照）は、クラス名に応じて別々のフォルダを作成します。これは、コードを他の実装と区別するのに役立ちます。

Answer 3

私は私の代理店で、最近、同じ問題を見てきたと私は現在、テストだソリューションは、以下のアプリのフォルダ構造が含まれます。

app/ 
    default/ 
      controllers/ 
      models, etc 
    ecommerce/ 
       controllers/ 
       models, etc 
lib/ 
    S24/ 
     ComponentCode.php 
modules/ 
     ecommerce/ 
        admin/ 
         controllers/ 
         models, etc 
        default/ 
          controllers/ 
          models, etc 
data, public web, temp, other ZF folders 

考え方は共通部品コードがlibに格納されていますモジュラーアプリケーションはmodulesに格納され、個々のクライアントWebサイトコードはappに格納されます。

lib/S24とmodules/ecommerceのフォルダは共通しており、プロジェクトごとに同じ（私たちはこれらの外部のSVNフォルダ）です。

appはモジュールディレクトリなので、defaultとecommerceフォルダはZF内にモジュールを作成します。app/defaultはデフォルト（つまり、モジュールなし）のコントローラ用です。 app/ecommerceには、コントローラーを単に拡張するコントローラーのセットが含まれています（modules/ecommerce/default/controllers内）。

希望すればapp/ecommerce/controllersの機能を拡張したり、新しい機能を追加することができます。

私たちはモジュール管理システムを同じに保ちたいと思いますし、複数の管理システム（www.domain.com/admin/ecommerceやwww.domain.com/admin/userのようなURL）をサポートしたいので、私たちはモジュール管理者システムを直接modulesフォルダから削除します。任意のカスタム管理ページをapp/admin/controllersに追加できます。

// Add Controller folder 
$front->addControllerDirectory('/path/to/modules/ecommerce/admin/controllers', 'ecommerceAdmin'); 

// Add route 
$router->addRoute(
    'ecommerceAdmin', 
    new Zend_Controller_Router_Route('admin/ecommerce/:controller/:action', 
            array('module' => 'ecommerceAdmin', 
              'controller' => 'index', 
              'action' => 'index')) 
); 

現在、私はこれをテストしていますが、自分のシステムにいくつかのアイデアがあることを願っています。これが完全に安定したら、そのトピックに関するブログ記事を書きたいと思っています。