なぜ誰もがコントローラーを1つのフォルダーに入れ、ビューを別のフォルダーに入れるのですか？

私は、aspから曲げてmvcフレームワーク、asp.net mvcまたはnancyに移行する準備をしています。どこに行っても、コントローラー/モジュール用のフォルダーとビュー用のフォルダーが表示されます。これは単にタイプごとに物事を片付けるパブロフの反射ですか、それともより深い知恵が働いていますか？一緒に開く可能性のあるファイルを一緒に保存する概念実証プロジェクトが少しありますが、かなり快適です。これらのファイルは相互に呼び出すことも多いため、短く、脆弱性の低い相対リンクで呼び出すことができます。フォルダーパスがURLパスに自動的に対応しなくなったため、このパターンはmvcによってチャレンジされ、asp.net mvcでは、プロジェクトテンプレートとルーティングがviews \ controllers \ schismを強制します。

このMicrosoftページでは、エリアの概念を紹介しています。これは、この人為的な分離が原因で、扱いにくい大型アプリがどのようになるかを認めたものとして読むことができます。

人々は「懸念の分離」に反対しますが、懸念の分離はすでに別々のソースファイルを持つことで達成されています。密結合されたこれらのソースファイルを取得し、フォルダー構造の反対側に送信することから、具体的なゲインはありませんか？

他の誰かがこれと戦っていますか？任意のヒント？

カーゴカルトプログラミングだと言いたいのですが、この構造には技術的な理由があります。Asp.Net MVCは、ほぼすべてに対して構成アプローチよりも規約を採用しました。デフォルトでは、RazorビューエンジンはViewsディレクトリを検索して、コントローラーから返されるビューを解決します。ただし、異なるプロジェクト構造を取得するためのハックがいくつかあり、MicrosoftはAreasと呼ばれるMVC機能を提供して、より健全なプロジェクト構造を作成できるようにします。ビューを探す場所を指定するために、独自のビューエンジンを実装することもできます。

なぜそれがカーゴカルトプログラミングであり、あなたがこれについて正しいと言うのですか？ボブおじさんは、プロジェクトのディレクトリ構造から、それがMVCアプリケーションであることを教えてはいけないと確信しました。店頭であること、または休暇申請システムであること、その他のことを教えてください。高レベルの構造とアーキテクチャは、実装方法ではなく、これが何であるかを教えてくれるはずです。

要するに、私はあなたがこれについて正しいと信じていますが、他のディレクトリ構造は単にフレームワークと戦っていて、Asp.Net MVCフレームワークにそれを行わせたくないと言うとき私を信頼するでしょうするように設計されていません。それは本当に設定可能ではないことは残念です。

アーキテクチャ上の懸念に迅速に対処するために、ビジネスモデル（ビジネスではなくビジネス）とDALは、MVCアプリから呼び出される別のプロジェクト/ライブラリに存在する必要があると考えています。

コントローラが実際にビューと非常に密接に結合されており、一緒に変更される可能性が高いというだけです。依存性による結合と論理的な結合の違いを覚えておくのは賢明です。コードの依存関係が分離されているからといって、論理的に結合しているわけではありません。

理由が何であれ、これは悪い練習です。パッケージまたはフォルダー（それらを呼び出すものは何でも）は、弱い相互依存関係を持つ必要があるため、非常に反オブジェクト指向です。それらの内部のクラス（またはファイル）は、強力な相互依存関係を持つ必要があります。

すべてのビューを1つのフォルダーに、すべてのコントローラーを別のフォルダーにスローすることにより、非常に密結合した2つのパッケージを作成します。これは、パッケージ間の依存関係が弱いという原則に反します。

ビューとコントローラーは全体の半分であり、互いに属している必要があります。左側の靴下用に1つの戸棚のドロー、右側の靴下用に別のドローはありません。

「なぜ...」と答えるには 質問：いくつかの潜在的な理由がありますが、実際には主観的な質問なので、どの組み合わせが本当の原因であるかは完全にはわかりません

• フォルダーと名前空間の構造が一致する論理アーキテクチャー（モデル、ビュー、コントローラー）を複製するには

• ASP.net MVCプロジェクトテンプレートに従う慣習と利便性

• Controllers/フォルダは.Controllers名前空間につながるため、名前空間でグループ化するには

• 可能性があるコントローラクラスは/両端-有する「コントローラ」（これは間違っているかもしれない）を含む名前空間からクエリ/スキャンしただけであるDI / IoCの中にいくつかのシナリオを有効にします

• T4テンプレートがスキャンを実行し、モデルとコントローラーをスキャフォールドしてビューを生成できるようにする

あなたのプロジェクトにとって理にかなっているなら、いつでもあなた自身の規約を作成し、それに従うことができます。ただし、大規模なプロジェクトや大規模なチームで作業する場合は、全員に知られているデフォルトの規則の方が適切な場合があることに注意してください（必ずしも正しいとは限りません！）

あなたの慣習が従うのがより簡単で、生産性を妨げないなら、ぜひそれをしてください！開発者コミュニティと交流してフィードバックを得るために、ブログの投稿を1つまたは2つ書くこともできます

ビューとコントローラーを別々のディレクトリに保持する理由の1つは、プロジェクトで作業するフロントエンドとバックエンドの開発者がいる場合です。フロントエンド開発者がバックエンドコードにアクセスするのを防ぐことができます（たとえば、PCIコンプライアンスを支援し、機密コードへのアクセス権を持つユーザーを制限します）。

もう1つの理由は、ビューパスを少し変更することで、「テーマ」を作成し、すべてのテンプレートを簡単に切り替えることができるようにすることです。

3番目の理由は、MVCフレームワークでビューを指定するときに単純なディレクトリパターンを使用することです。各ビューへの大きな長いパスではなく、サブディレクトリとファイルを指定する方が簡単です。

唯一の「密結合」は次のとおりです。

1. コントローラーによってビューに送信される変数。
2. ビューのフォームフィールドまたはアクション。コントローラーに送り返されます。

多くのビューが同じコントローラーを使用でき、多くのコントローラーが同じビューを使用できるように、汎用コントローラーを使用してビューの変数名を汎用に保つようにします。このため、ビューを完全に分離することを好みます。モデルは、アプリケーション内の各「もの」を区別できる場所です。これらは、プロパティのリストとこれらのプロパティにアクセス/変更するメソッドを持つオブジェクトにすることができます。

密結合コードの場合、パッケージまたは「モジュール」の一部であるすべてのファイルを名前空間のディレクトリにまとめて保持するのが効果的です。次に、スクリプトを使用して、rawテンプレートをメインの「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としても機能させる場合に特に役立ちます。ジェネリック変数名を使用して、ビューをデータから切り離してみてください。多くのコントローラーまたはモデルに同じテンプレートを使用できます（または、インクルードを使用して、維持する必要があるコードの量を最小限に抑えます）。

必ずしも誰もがこれを行うとは限りません。たとえば、Pythonの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として公開するだけで、他のサイトでそのモジュールを使用できます。

コントローラーとビューを別のフォルダーに保存するのはマイクロソフトが推奨する方法であるため、多くは推奨される構造に従うため、

1. 理由の1つは、コントローラーが常にビューと1対1の関係を持たない可能性があることです。特に、部分ビューはコントローラー間で共有できます。
2. 別の理由としては、プロジェクトが大きくなった場合、コントローラーとユニットテストを別のプロジェクトにプルする必要があるかもしれませんが、ビューとビュー/ js / cssが相互に参照するために一緒に属する場合、同じことを行うのはかなり困難です。

など、それをあなたの方法をやっについて多くの記事があることを言って、これは。

記録のために

なぜそれがカーゴカルトプログラミングであり、あなたがこれについて正しいと言うのですか？ボブおじさんは、プロジェクトのディレクトリ構造がMVCアプリケーションであることを教えてはいけないと私に確信させました。店頭であること、または休暇申請システムであること、その他のことを教えてください。高レベルの構造とアーキテクチャは、実装方法ではなく、これが何であるかを教えてくれるはずです。

質問：コードにアクセスできるのは誰ですか？プログラマ。エンドユーザーはコードを気にしますか？いいえ。そして、プログラマーが行うこと、コード。より具体的には、タイプ（コントローラー、サービス、モデルなど）に基づいたクラス。したがって、コードの動作ではなく、コードの種類に基づいてコードを見つけることができれば、それは理にかなっており、コードをデバッグするのは簡単です。さらに、チームプロジェクトを考えてみましょう。1人はコントローラー、もう1人はモデル、もう1人はdao、もう1人はビューを担当しています。プロジェクトをパーツに分割するのは簡単です。良いコードとは、構文シュガーコードではなく、デバッグしやすいコードです。ボブおじさんはまた間違っている。

プロジェクト（店頭）の振る舞いを模倣しようとするのは、貨物カルトです。