3

私はほとんどのプロジェクトで使用してきたやや原始的なフレームワークを持っていますが、まだ解決できていない一般的な設計上の問題が頭に浮かびました。特定のアプリケーションについて、アプリケーション固有のクラス構造をフレームワークの構造から分離する必要がありますか、それともフレームワークの上に構築することはそれほど悪いことではありませんか?

たとえば、ベースの Controller クラスを持つフレームワークがあり、それをアプリケーションの特定の部分に拡張したとします。最も理にかなっている配置はどれですか?その理由は?

クラス構造 A:

  • 直感的で、デバッグ時にソース ファイルを簡単に見つけることができます。
  • ファイルの命名/ディレクトリ構造は、クラス階層を反映しています。
- Framework_Control "Framework\Control.php"
   - Framework_Control_Index "Framework\Control\Index.php"
   - Framework_Control_Home "Framework\Control\Home.php"
   - Framework_Control_Contact "Framework\Control\Contact.php"
   - Framework_Control_About "Framework\Control\About.php"

クラス構造 B:

  • フレームワークのモジュールを維持し、簡単に交換/更新できます。
  • ディレクトリ構造がいくらか複雑になり、ディレクトリ/ファイルの命名が常にクラス階層に従わなくなりました。
- Framework_Control "Framework\Control.php"
   - Application_Control_Index "Application\Control\Index.php"
   - Application_Control_Home "Application\Control\Home.php"
   - Application_Control_Contact "Application\Control\Contact.php"
   - Application_Control_About "Application\Control\About.php"

全体的には個人的な好みに帰着することはわかっていますが、どの方法を選択するかを決定する前に、すべての長所と短所を比較検討したいと思います. 実際の階層はどちらの場合も同じままであるため、実際にはクラスの命名とディレクトリ構造に帰着します。

4

2 に答える 2

2

ソース コードを 2 つの異なるカテゴリで表示することをお勧めします。外部の依存関係または複数のサイトで使用され、どのサイトにもネイティブではないコードと、ネイティブの依存関係または作業している特定のサイトにネイティブなコードです。 .

Framework/Control.php はより大きな外部依存関係の一部であり、そのように管理する必要があるように思えますが、Application/Control ファイルはすべて特定の Web サイトにネイティブです。

この差別化をコード構造に使用することで、社内フレームワークを複数のサイト間で非常に簡単に再利用できるようになりました。

最後に、Zend Framework、Symfony などの主要なフレームワークが何を行っているかを検討することを検討してください。フレームワーク全体はあなたが望む以上のものかもしれませんが、フレームワークの構造は、PHP 開発者が世界中で使用している一般的な優れたプラクティスについて多くの洞察を提供できます。

于 2008-10-21T01:51:07.473 に答える
1

つまり、アプリケーション XYZ で Framework\Control.php を更新するときに何をするかということです。アプリケーション ABC に戻って、同じ変更を行いますか? 重大なバグの場合はどうなりますか?

すべてのプロジェクトの保守性のために、2 番目のオプションを使用します。

于 2008-10-20T23:58:37.247 に答える