php - 集合 - MVCアプリケーションの構造がコンパクトではない理由




開集合 (2)

Web MVCプロジェクトでは、次のような構造になっています。

mymvc/                      -> Project root.
    public/                 -> Document root. The only one folder accessible from web.
        assets              -> Client-side assets. NOT ONLY for global themes and libraries, BUT ALSO for each specific "view" controlled by the "src/Application" components.
            css/
            js/
            images/
            ...
        index.php           -> Application's entry point.
    src/                    -> UI layer rules.
        Application/
            Controller/
            View/
            ViewModel/
        Dispatcher/         -> Application dispatching - route matching, dispatching to the specified controller, etc.
        ...                 -> Other classes used by the components in the "src/Application" folder.
    templates/              -> Layout and template files.

注:すべてのドメインモデルコンポーネント(エンティティ、リポジトリ、データマッパー、サービスなど)は、 mymvcディレクトリの外部のフォルダにmymvcされているため、他のアプリケーションからもアクセスできます。

私は、次の2つのステップを実行することについて考えました。

  1. templatesディレクトリをsrc/Applicationフォルダに移動します。
  2. assetsディレクトリをsrc/Applicationに移動し、Webサーバー(Apache)設定内にエイリアス/assets/を作成し、移動したフォルダをポイントし、外部からのアクセスを許可します。

cssテーマ、jsライブラリコード、背景画像など、グローバルに使用されているアセットは、依然としてpublicディレクトリに配置されたままになります - 明らかに名前が付けられたまたはエイリアスが付けられたassetsは配置されません。

2つのステップは非常に良いアイデアだと思います。これは、見てのとおり、両方のフォルダーにsrc/Application構造に関連するリソースが含まれているためです。 だから、このようなものを持っている代わりに:

  • src/Application/Controller/AboutUs.php
  • public/assets/js/AboutUs.js
  • templates/AboutUs/[multiple-layout-and-template-files]

次のような構造がはるかに優れているようです。

  • src/Application/Controller/AboutUs.php
  • src/Application/assets/js/AboutUs.js
  • src/Application/templates/AboutUs/[multiple-layout-and-template-files]

しかし、私は多くのWebフレームワークを研究した後、それらすべてが2つのフォルダー( templatesassets )をアプリケーションフォルダーから完全に分離した状態に保つことに気付きました。

それで、私は尋ねたいと思います:私が提案した2つのディレクトリの移動ができない、または行うべきではないのはなぜですか?

ありがとうございました。


コードを分類する

私がお勧めする唯一のことは、自動ロードを簡単にするために、ネームスペースをディレクトリ構造と同じにすることです。 そこから、言語はコードがどのように編成されているかを気にしません。 2つの制限は名前空間とディレクトリです。これらは階層的です。 そのため、コードを階層構造でしか分類できないと判断されます。

実際の問題は、 階層的分類がそれ自体問題であるということです。 オブジェクトはさまざまな方法で分類できます。 幸いなことに、PHPは分類を意識していません。 なぜなら私たちは実際にコードとオブジェクトについて考えているからです。 私たちはそれらを探し、使って、育てます。 それは単に個人的な経験と好みの問題です、あなたの特定の物の行動との最も強い関連は何ですか?

考慮すべきことがもう1つあります。「地獄は他の人です」。

あなたの分類が他のものと互換性を保つことは、あなたのコードがその特定のフレームワークに依存し始めたら、役に立つでしょう。 または他の人の分類体系はあなたが従うことをいとわない何かである可能性があります。

いずれにせよ、 あなたが望むことをしない理由ありません 。 後で、あなたが自分の考えを変えたとしても、少なくとも自分がなぜ自分がそれを変えたのかを知ることができ、そこから学ぶことができます。


それはすべてあなたが達成したいこと、そしてあなたのワークフローが何であるかによって異なります。 あなたはPHPで働いているようです - Ruby on Railsのような非PHPフレームワークを見る価値があります。

通常は、出力フォルダを「読み取り専用」にします。開発者は手動でファイルを編集しないでください。代わりに、ビルドおよびデプロイパイプラインでGradleなどのツールを実行して( /sourceフォルダから)SASS / LESSおよびJSファイルをCSSに変換します。 Javascriptを縮小/連結して/public正しい場所に配置します。 ビルドパイプラインとデプロイパイプラインは、開発ビルドとプロダクションビルドで異なる設定を持つことがよくあります(たとえば、プロダクション専用に縮小する)。

Ruby on Railsでは、「テンプレート」が「レイアウト」と呼ばれる「ビュー」の下のフォルダーであることを除いて、構造はほとんど「はるかに優れている」と記述したとおりです。 さまざまなアセットファイル(SASS / LESS、JSなど)を変換するビルドステップ(自動的に実行されます)があります。

here Ruby on Railsディレクトリ構造の詳細な説明を見ることができhere 。 Djangoのディレクトリ構造はhereで説明さhere

あなたのコメントの中の質問に答える:

  • SASS / LESS / JS / Coffeeスクリプトファイルはどこに行くべきですか? - あなた次第。 Railsでは、それらは/app/assets/javascript sと/app/assets/stylesheets 。 これらのフォルダには、ビューごとに1つのファイルと、アプリケーションレベルのファイルがあります。 これはあなたのビルドプロセスを素晴らしくそして簡単にします - あなたが心配するべき2つのフォルダーだけを持ち、そしてあなたがあなたが新しいビューを作成する度にあなたのビルドを修正する必要はありません。
  • ビューの構成方法 - アプリケーションレベルのビューと特定のページビューがあります。 繰り返しますが、主に便利さの問題です。 Railsでは、すべてのテンプレート - /app/views下にあり/app/views 。 アプリケーションレベルのビューは、 /app/views/layoutsという名前のフォルダにあります。ページレベルのテンプレートとそれほど違いはありません。そのため、それらをフォルダから移動してもあまり効果はありません。同じ最上位フォルダでビルドと設定が簡単になります。

それで、いいえ、あなたが提案することをする理由はありません。





directory-structure