6

asp.net mvc（4）では、箱から出して、ビューはフォルダーに移動し、コントローラーごとViewsにサブフォルダーにグループ化されます。

コントローラーはControllersフォルダーに移動し、（表示/編集/入力）モデルはModelsフォルダーに移動します。

ビューを整理する方法が好きです。ただし、残りのMVCピースを水平方向に分割するのは好きではありません。

私の質問は、ビューの組織構造をそのままにして、他のクラスをコントローラーごとに（つまり、ユースケースごとに）グループ化することの欠点は何でしょうか。例えば：

/Home
  HomeController.cs
  IndexViewModel.cs
  IndexViewModelBinder.cs
/Messages
  MessagesController.cs
  MessagesApiController.cs
  MessagesViewModelBinder.cs
  MessageViewModel.cs
  MessagesListViewModel.cs
/Views
  /Home
     Index.cshtml
  /Messages
     MessagesIndex.cshtml
     MessageDetails.cshtml
4

2 に答える 2

3

View ファイルは実行時にアクセスされるため、重要なのは View ファイルの配置だけです。それ以外はすべてアセンブリにコンパイルされるため、ソース ファイルの物理的な場所は関係ありません。

あなたと同じように、大規模なプロジェクトではデフォルトの配置が少し厄介だと思うので、現在のプロジェクトを次のようにレイアウトします。

~/
    /Areas
        /DefaultArea // I always use areas, even when there's only one, because it simplifies things when adding additional areas.
            /Controllers
                FooController.cs
            /Views
                /Foo
                    FooView.aspx // Yes, I use WebFormView. Just a matter of personal preference
                    FooEdit.aspx
                    FooModels.cs // this file contains my ViewModels

したがって、基本的には、すべての ViewModel を一緒に配置するのではなく、ViewModel クラスをビューと同じフォルダーに配置します (これは論理的な意味がありません)。コントローラーをビューのフォルダーに配置したくなりましたが、やめることにしました。

これまでのところ、私のアプローチの欠点は見つかりませんでした (ほぼ 2 年間使用しています)。

于 2012-09-11T23:19:41.203 に答える
1

ルーティングでいくつかの問題が発生するため、可能な限りエリアを避けるのが一般的です。

あなたの構造は完全に問題ないと思います（そして、「関数」ではなく「タイプ」に基づいてコードを分離するデフォルトのMVC / Web構造よりも優れています）。

私が提案するのは、「Web」.csファイルのみをWeb DLL（コントローラー、ViewModel、バインダーなど）に保持し、ドメイン/サービス/などのレイヤーの個別のDLLに同じ構造を持たせることです。必要に応じて、個別に再利用/テストできます。

于 2012-09-12T02:10:20.373 に答える