ASP.NET MVC: Grupowanie klas wokół kontrolera

W asp.net mvc (4), po wyjęciu z pudełka, widoki przechodzą do folderu Views, a następnie pogrupowane według kontrolerów w podfolderach.ASP.NET MVC: Grupowanie klas wokół kontrolera

Kontrolery przejść do folderu Controllers (View/Edit/wejście) modele przejść do Models folderu itp

lubię drodze widoki są zorganizowane. Nie lubię jednak łamać pozostałych elementów MVC w poziomie.

Moje pytanie brzmi, jakie byłyby wady pozostawiania struktury organizacyjnej widoków w obecnej postaci, ale grupują inne klasy według kontrolera (np. Przez przypadki użycia). Np .:

/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

Źródło

2012-09-11 THX-1138

To w dużej mierze dotyczy obszarów. –

Obszary będą grupować powiązane elementy razem, prawda, ale nadal będziesz mieć 5 kontrolerów w jednym folderze i 10 przeglądać modele w innym folderze. So Areas rozwiązują ten problem, ale nie jest to rozwiązanie, które przedstawiłem. –

Wszystko, co ma znaczenie, to rozmieszczenie plików widoku, ponieważ są one dostępne w czasie wykonywania. Cała reszta jest wkompilowana w zespół, więc fizyczna lokalizacja plików źródłowych jest nieistotna.

Jak ty znajdę układ domyślny nieco niewygodne dla większych projektów, tak to jest, jak kładę moje aktualne projekty:

~/ 
    /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

Więc w zasadzie, kładę moje klasy ViewModel w tym samym folderze co widoki zamiast łączenia wszystkich modeli ViewModels (co czyni mniej logicznym). Kusiło mnie, żeby umieścić kontrolerów w folderach ich widoków, ale zdecydowałem, że nie.

Nie znalazłem żadnych wad w stosunku do mojego podejścia do tej pory (używam go prawie 2 lata).

Źródło

2012-09-11 23:19:41 Dai

Generalnie lubię unikać obszarów, gdzie to możliwe, ponieważ stwarza to pewne problemy z routingiem.

Myślę, że twoja struktura jest całkowicie w porządku (i przewyższa domyślną strukturę MVC/Web kodu separującego w oparciu o "typ" raczej dziękuję "funkcja").

Wszystko, co chciałbym zasugerować to to, że przechowujesz tylko pliki ".cs" w internetowej bibliotece DLL (np. Kontrolery, ViewModele, Segregatory itp.) I mają tę samą strukturę w oddzielnych bibliotekach DLL dla domen/usług/etc warstw, aby można je ponownie użyć/przetestować osobno, jeśli/w razie potrzeby.

Źródło

2012-09-12 02:10:20

ASP.NET MVC: Grupowanie klas wokół kontrolera

Odpowiedz

Powiązane problemy