3

当社がほとんどのプロジェクトのベースフレームワークとしてZendFrameworkの使用を開始したため、すべてのプロジェクトでいくつかの共通要素を共有したいと考えています。私は次のようなことについて話します:

  • モデルの実装(doctrine2に基づく)
  • ユーザー、グループ、ロールモデルを含むモデルのRBAC
  • ajaxバックエンドインターフェース用のxmlベースのテンプレートエンジン
  • (あなたはそれに名前を付けます)..。

基本的に、「手に負えないもの」を置いて実行するためのすべてのもの。これらのコンポーネントをパッケージ化するための最良の方法は何ですか?2つの可能性があります。

モジュールとして

必要な機能を個別のモジュールとしてmodulesフォルダーに含めます。

プロ:

  • ルートを設定してコードを実行できます。これは多くのモジュールに適しています(想像上の例:paypalモジュールには何らかのコールバックURLが必要です。モジュールが独自に設定できる場合は、「プロジェクト開発者」による構成は必要ありません) 。
  • 箱から出して実際の機能(ユーザー管理など)を提供できます
  • 自動読み込みや教義などを設定するためのブートストラップがあります。

短所:

  • 悪い場所?ユーザープロジェクトに干渉する
  • プロジェクト間で共有するのが少し難しい(クラスパスの代わりにgitサブモジュール)

ライブラリフォルダ内

ライブラリフォルダに配置し、クラスパスをポイントします。

プロ:

  • クリーンなソリューション
  • プロジェクト間での共有

短所:

  • ブートストラップは明示的に呼び出す必要があります
  • 直接のルーティングやアクションは不要です。具体的なプロジェクトを通じてすべてをプロキシする必要があります。

では、これをどのように解決しますか?再利用可能な汎用のものをzfのどこに配置しますか?

4

1 に答える 1

1

私はあなたが両方のアプローチを使うべきだと思います。

「インフラストラクチャ」クラスやその他の再利用可能なもの(ZF独自のコンポーネント、Doctrine 2のコンポーネントなど)のように、「ライブラリのような」コードを開発する場合は、それらをライブラリディレクトリに配置できます。(または独自の完全に別個のプロジェクト)

実際のZFモジュール(たとえば、認証モジュールなど)を開発するときは、ZFモジュール構造を中心にコードをフォーマットします。

この種のアプローチを使用することで、リストしたすべてのメリットが得られると思いますが、デメリットはほとんどありません:)

追加のアイデアの1つとして、アーキテクチャパーツを「サービス」として開発する場合は、それらを独自のWebサービスエンドポイントとして実行し続けることもできます。

于 2011-07-15T10:41:52.957 に答える