2

Zend Framework を利用した e コマース プラットフォームを開発しています。同じコード ベースを使用して、アプリケーションのインスタンスをいくつか稼働させています。構成設定は、さまざまなショップを区別するために使用されます。

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

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

どんなポインタでも大歓迎です！

4

3 に答える 3

2

最近私の代理店で同じ問題を調べており、現在テストしているソリューションには、次のアプリ フォルダー構造が含まれます。

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ます。

およびフォルダーは共通であり、各プロジェクトで同じです (これらのフォルダーの外部に SVN を作成します) lib/S24。modules/ecommerce

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'))
);

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

于 2009-05-12T21:35:39.260 に答える
0

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

ここでの問題は、コードが何もオーバーライドせず、機能を追加することに言及していることです。おそらく、クラス名を含む構成ファイルを読み取るプラグインシステムの形式を見ているでしょう。これらのクラスは、各プラグインに関する情報を提供します（つまり、UIがタブを使用する場合、タブの名前のプロパティがあります）。

それは実際には、実装ごとにどのような機能が異なるかによって異なります。高レベルのソリューションを提供するために、より多くの情報があると役立つ場合があります。

PHPオートロードを使用する方法（「OOPが異なるファイルに格納されているクラスを「含める」方法を参照）は、クラス名に応じて個別のフォルダーを作成します。これは、コードを他の実装から分離するのに役立つ場合があります。

于 2009-05-12T19:42:21.800 に答える
0

お客様のプラットフォームに似たサービス アプリケーションとしてのソフトウェアを運用しています。この場合、すべてのインスタンス データはインスタンス独自のデータベースに保存されます。

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

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

于 2009-05-12T12:15:29.513 に答える