なぜ誰もがコントローラを1つのフォルダに配置し、ビューを別のフォルダに配置するのですか？
私は曲がりをaspから取り出して、mvcフレームワーク、asp.net mvcまたはnancyに取り込む準備をしています。どこに行っても、コントローラ/モジュールのフォルダとビューのフォルダが表示されます。これはタイプ別に整理するパブロフの反射だけですか、それとも、より深い知恵が働いていますか？一緒に開く可能性が高いファイルを一緒に保存するという概念実証プロジェクトがあり、かなり快適です。これらのファイルも相互に呼び出す可能性が高いため、相対的にリンクが短く、壊れにくくなっています。フォルダーパスがURLパスに自動的に対応しなくなり、asp.net mvcでは、プロジェクトテンプレートとルーティングにより、views\controllers\schismが強制されるため、このパターンはmvcに挑戦されます。
この Microsoftページ は、エリアの概念を紹介しています。これは、この人工的な分離が原因で大きなアプリが扱いにくくなることの承認として読むことができます。
人々は「懸念の分離」に異議を唱えるでしょうが、懸念の分離は、個別のソースファイルを用意することですでに達成されています。密に結合されたこれらのソースファイルを取得し、フォルダー構造の反対側の端に送信することから、具体的なメリットはないようです。
他に誰かがこれと戦っていますか？任意のヒント？
貨物カルトプログラミング と言いたいのですが、この構造には技術的な理由があります。 Asp.Net MVCは、ほぼすべての構成アプローチに慣例を採用しました。デフォルトでは、RazorビューエンジンはViewsディレクトリを検索して、コントローラーから返すビューを解決します。ただし、異なるプロジェクト構造を取得するための hacks がいくつかあり、Microsoftは Areas と呼ばれるMVC機能を提供して、より健全なプロジェクト構造を作成できるようにしています。 独自のビューエンジンを実装する でビューを探す場所を指定することもできます。
なぜそれがカーゴカルトプログラミングであり、あなたはこれについて正しいと言うのですか？ ボブおじさんが私を納得させた プロジェクトのディレクトリ構造は、それがMVCアプリケーションであることを私に知らせてはならない。店頭か、休暇申請システムか、なんでもいいと教えてくれるはずです。高レベルの構造とアーキテクチャはwhatについて教えてくれますhowではありません.
要するに、私はあなたがこれについて正しいと信じていますが、Asp.Net MVCフレームワークにそれ以外のことをさせたくないと言ったとき、他のディレクトリ構造は単にフレームワークと戦っていて、私を信頼します。行うように設計されていません。それが実際にはもっと設定できないのは残念です。
アーキテクチャの問題にすばやく対処するために、ビジネスモデル（ビューではなくビジネス）とDALは、MVCアプリから呼び出される別のプロジェクト/ライブラリに存在する必要があると私はまだ信じています。
コントローラーがビューと非常に緊密に結合されており、一緒に変更される可能性が高いだけです。依存関係による結合と論理結合の違いを覚えておくのは賢明です。コードの依存関係が分離されたからといって、論理的に結合が弱くなるわけではありません。
理由が何であれ、これは練習としては不十分です。パッケージまたはフォルダー（それらを呼び出すものは何でも）の相互依存関係が弱いため、これは非常にオブジェクト指向です。それらの内部のクラス（またはファイル）は、強い相互依存関係を持つ必要があります。
1つのフォルダーにすべてのビューをスローし、別のフォルダーにすべてのコントローラーをスローすることで、非常に緊密な結合を持つ2つのパッケージを作成しています。これは、パッケージ間の依存関係が弱いという原則に反します。
ビューとコントローラーは全体の2つの半分であり、互いに属している必要があります。左側の靴下には1つの食器棚のドローがなく、右側の靴下には別のドローがあります。
「なぜみんな...？」質問：いくつかの潜在的な理由がありますが、実際には主観的な質問であるため、どの組み合わせが本当の原因であるかは完全にはわかりません
一致するフォルダーと名前空間の構造を持つ論理アーキテクチャー（モデル、ビュー、コントローラー）を複製するには
ASP.net MVCプロジェクトテンプレートに従うための慣習と利便性の範囲外
名前空間でグループ化するには、
Controllers/フォルダは.Controllers名前空間Might DI/IoCで一部のシナリオを有効にします。ここでは、コントローラークラスは 'Controllers'を含む/で終わる名前空間からのみ照会/スキャンされます（これは間違っている可能性があります）
T4テンプレートがモデルとコントローラーをスキャンして足場を作成し、ビューを生成できるようにするため
プロジェクトに意味がある場合は、いつでも独自の規則を作成して従うことができます。誰もあなたを止めることはできません。ただし、大規模なプロジェクトや大規模なチームで作業している場合は、誰もが知っているデフォルトの規則の方が適している可能性があることに注意してください（ただし、正しい規則とは限りません）。
あなたの慣習が従うのがより簡単で生産性を妨げないなら、それなら必ずそれをしてください！ブログ投稿を1〜2回書いて、開発者コミュニティと交流し、フィードバックを得ることもできます
ビューとコントローラーを別々のディレクトリに保持する理由の1つは、フロントエンドとバックエンドの開発者がプロジェクトで作業している場合です。フロントエンド開発者がバックエンドコードにアクセスできないようにすることができます（たとえば、PCIコンプライアンスを支援し、機密コードへのアクセス権を持つユーザーを制限します）。
もう1つの理由は、ビューのパスに小さな変更を加えることで、「テーマ」を簡単に作成して、テンプレートのallを切り替えることです。
3番目の理由は、MVCフレームワークでビューを指定するときに単純なディレクトリパターンを使用するためです。各ビューへの長い長いパスよりも、サブディレクトリとファイルを指定する方が簡単です。
唯一の「密結合」は次のとおりです。
- コントローラーによってビューに送信される変数。
- ビュー内のフォームフィールドまたはアクション。コントローラーに送り返されます。
私は汎用コントローラーを使用して、ビュー名に変数名を保持しようとしています。これにより、多くのビューが同じコントローラーを使用でき、多くのコントローラーが同じビューを使用できます。このため、私はビューを完全に分離しておくことを好みます。モデルは、アプリケーション内の各「もの」を区別できる場所です。これらは、プロパティのリストとこれらのプロパティにアクセス/変更するためのメソッドを持つオブジェクトである場合があります。
緊密に結合されたコードの場合、機能する可能性のあるアプローチは、パッケージまたは「モジュール」の一部であるすべてのファイルを名前空間付きディレクトリにまとめることです。次に、スクリプトを使用して、生のテンプレートをメインの「views」ディレクトリにコピーまたは「コンパイル」できます。例えば：
lib/my-namespace/my-package/
-> controllers/
-> models/
-> views/
-> theme/
-> template-name1
app/compiled_views/theme/
-> url/path/template-name1
残念ながら、既存のテーマの構造を変更したい場合は、ビューを更新するためにパッケージディレクトリに出入りする方法が増えます。
ビューは、json、xml、csv、またはhtmlのいずれであっても、データをフォーマットするための単なる方法であると考えてください。これは、アプリケーションをAPIとしても機能させる場合に特に役立ちます。ジェネリック変数名を使用して、ビューをデータから切り離し、多くのコントローラーまたはモデルに同じテンプレートを使用できるようにします（または、インクルードを使用して、維持する必要があるコードの量を最小限に抑えます）。
コントローラとビューを別のフォルダに保存するのは Microsoftが推奨する方法 であることを忘れないでください。
- 1つの理由は、コントローラーがビューと常に1対1の関係を持たないことです。特に、部分的なビューはコントローラー間で共有できます。
- 別の理由としては、プロジェクトが成長したときに、コントローラーと単体テストを別のプロジェクトにプルしたい場合がありますが、ビューとビュー/ js/cssが同じように実行することは、お互いを参照しているため、一緒に行うのはかなり困難です。
this のように、あなたのやり方でそれを行うことについての多くの投稿があると言いました。
必ずしも全員がこれを行うとは限りません。たとえば、pythonのDjangoフレームワークにはアプリの概念があり、アプリケーションのサブモジュールは、独自のモデルとビューおよびテンプレートを持つ独自のディレクトリにあります（ビューはDjangoは基本的にコントローラーを呼び出します。それは、「アプリ」をパッケージ化し、プロジェクト設定のアプリリストに含めるだけでプロジェクト間で簡単に再利用できることを意味するので、私はたまたまそうした方法を好みます。それはまた、さまざまな部分がどこにあるのかを簡単に見つけることができます。urls.pyファイルを見てurl(r'^users/', include('my_site.users.urls'))のようなものを見ると、モジュールmy_site.usersには、ユーザーを処理するすべてのコードが含まれています。私はモジュールを見ることを知っていますmy_site.users.viewsおよびmy_site.users.modelsユーザーの作成方法と認証方法を確認したい場合。私のルートはすべてmy_site.users.url。
また、汎用的である場合は、構成を変更するか、ライブラリとしてパッケージ化してOSSとして公開するだけで、おそらく他のサイトでそのモジュールを使用できます。
記録のために
なぜそれがカーゴカルトプログラミングであり、あなたはこれについて正しいと言うのですか？ボブおじさんは、プロジェクトのディレクトリ構造はMVCアプリケーションであることを教えてはならないと私に確信させました。店頭か、休暇申請システムか、なんでもいいと教えてくれるはずです。高レベルの構造とアーキテクチャは、これがどのように実装されたかではなく、これが何であるかを教えてくれるはずです。
質問：コードにアクセスできるのは誰ですか。プログラマー。エンドユーザーはコードを気にしますか？いいえ。そして、プログラマが行うことはコードです。より具体的には、タイプに基づくクラス（コントローラー、サービス、モデルなど）。したがって、コードの動作ではなく、コードのタイプに基づいてコードを見つけることができれば、コードをデバッグするのは理にかなっており、簡単です。さらに、チームプロジェクトで、1つはコントローラー、もう1つはモデル、もう1つはdao、もう1つはビューを担当しているとします。プロジェクトをパーツに分割するのは簡単です。良いコードは、デバッグが容易なコードであり、構文糖コードではありません。ボブおじさんはまた間違っている。
プロジェクト（店先）の動作を模倣することは、カーゴカルトです。