0

私は2つのモジュールを持つZF1+Doctrine2アプリを開発しています。デフォルトはデフォルトの標準Webサイトであり、「rest」はRESTインターフェースを提供します。明らかに、両方のモジュールは多くの共通のDB操作を共有しているため、同じモデルを使用します。私のアーキテクチャの目標は、コントローラーからDoctrine EMメソッドを呼び出さないようにし、その上に抽象化レイヤー（一種のAPI）を作成して、分離とコードの一貫性を保つことです（個人的には、モデルを呼び出したり、コントローラーでクエリを作成したりするのは好きではありません）しかし、私は間違っているかもしれません）。

モデルをライブラリ（/library//Users/Users.phpなど）に入れたくなりましたが、モデルがアプリケーションフォルダーにあるという理由だけで、ライブラリがここで適切かどうかはわかりません。モデルはZFクラスを拡張しません。しかし、ライブラリはアプリケーション全体で共有されているため、私はそれを検討しました。

私が思いついた他のオプションは、それをapplication / modules / default / modelsに置くことですが、そうすると、それらのモデルはグローバルですが、他のモジュールから論理的に分離されます。

この場合、どちらの解決策が優れていますか、それとも適切に行うために言及しなかった他の方法はありますか？

4

2 に答える 2

2

クロスプロジェクト用にライブラリ フォルダーを保持しようとしています。これは、ドロップインして直接使用するか、独自のクラスで拡張するライブラリの一種のベンダー フォルダーです (必要に応じて autoloadernamespaces エントリを追加します)。

マルチモジュール アプリケーションでは、共通モデル、マッパー、ビュー ヘルパー、すべてのモジュールで使用される部分スクリプトなど、クロスモジュールのものをアプリケーション レベルで保持し、appnamespace (Application_またはMy_そのようなもの) で名前を付けます。 ）。次に、デフォルト モジュールを含むすべてのモジュールをプッシュします。-modulesフォルダーに。モジュール固有のもの (コントローラー、フォーム、ビューなど) は、モジュール名で名前空間化されます。何かのようなもの：

/application
    /configs
        application.ini
    /layouts
    /models # app-level!
    /modules
        /admin
            /controllers
            /forms
            /models
            /views
                /helpers
                /scripts
        /front
            /controllers
            /forms
            /models
            /views
                /helpers
                /scripts
    /views  # app-level!
        /helpers
        /scripts    
/data
    /cache
/library
    /App
    /Zend
/public
    index.php
    /assets
        /css
        /img
        /js
/scripts

通常、モジュール ブートストラップ クラス (拡張Zend_Application_Module_Boostrap) は、正しいリソース オートローダー マッピングを登録して、オブジェクトのインスタンス化を簡単にします。

1 つのメモ: 私のコントローラーは、それらが存在するモジュールの名前空間を使用することを好むので、frontcontroller にパラメーターを設定して、コントローラーにそれを認識させる必要があります。

resources.frontController.params.prefixDefaultModule = true

tl:dr:

  • クロスプロジェクト クラスlibraryは、独自の lib 名前空間に存在し、使用します。
  • アプリ レベルのクロスモジュール クラスはアプリ レベルに存在し、appnamespace を使用します。
  • モジュール レベルのクラスはモジュール フォルダーに存在し、モジュールの名前空間を使用します。
于 2012-05-19T13:07:06.407 に答える
1

ZF 1.x は実際にはモジュラーではなく、ZF 1.x のモジュールは少し間違った名前だと思います。私の意見では、それらはドメインライブラリに似ています。そうは言っても、私はコード分離をこのように見ています（純粋な意見）。

  • ライブラリに配置した別のプロジェクトで再利用または再利用できると予想されるコード。例えば。ビュー ヘルパー、アクション ヘルパー、抽象モデル クラス、基本モデル、プラグインなど...

  • アプリケーション固有のコードで、アプリケーション レベルのディレクトリに配置したアプリで普遍的に使用されるコード。具体的なデータ マッパー、DbTable モデル (Doctrine は使用していません)、フォーム、レイアウトなどです。

  • 特にモジュール (ドメイン) に属し、モジュール レベルのディレクトリに配置した他の場所では使用しない、または使用できないコード。これには、フォームの 1 つである特別なビューおよびアクション ヘルパーのようなものが含まれます。ほとんどの場合、ドメイン (エンティティ) モデルを配置する場所です。

これを説明するために、例を示します (個人の名前空間は省略します)。

アプリケーションにmusicという名前のモジュールがあり、このモジュールには'music'という名前のデータベース テーブルがあります。
したがって、これらはモジュールでこの Db テーブルを使用するために必要なファイルです。

//The DbTable model
application
    /models
        /DbTable
            /Music.php //extends Zend_Db_Table_Abstract

その DbTable モデルを使用するために、2 つのファイルを使用するマッパーを作成します

//Base mapper class
library
    /Application
        /Model
            /Mapper.php
//The concrete mapper
application
    /modules
        /models
            /MusicMapper.php //extends Namespace_Application_Model_Mapper

そのマッパーを使用するには、基本エンティティ クラスと具象エンティティ クラスの 2 つのファイルで構成されるドメイン モデルを作成します。

//Base entity class
library
    /Application
        /Model
            /Entity.php

//and the concrete entity class
application
    /modules
        /models
            /Music.php //extends Namespace_Application_Model_Entity

ファイルとクラスをこのように整理すると、混乱したり散らばったりすることなく、コードをできるだけ DRY に保つことができます。

これが役立つことを願っています。

于 2012-05-19T08:40:44.773 に答える