Najlepsze praktyki dotyczące architektury MVC [zamknięte]

Moje pytanie dotyczy bardziej sposobu projektowania aplikacji MVC. Na przykład zachęcamy do korzystania z DI z wzorcem repozytorium w celu oddzielenia dostępu do danych od kontrolera, jednak bardzo mało mówi się na temat tego, jak to zrobić specjalnie dla MVC. Gdzie na przykład umieścilibyśmy klasy Repozytorium? Wydaje się, że nie są one związane konkretnie z modelem, ponieważ model powinien być względnie oddzielony od rzeczywistych technologii dostępu do danych.

Drugie pytanie dotyczy sposobu strukturyzacji warstw lub poziomów. Większość przykładowych aplikacji (kolacja Nerd, Music Store itp.) Wydaje się korzystać z jednowarstwowego, dwuwarstwowego podejścia (nie licząc testów), w którym zazwyczaj kontrolery bezpośrednio wywołują kod L2S lub EF.

Jeśli chcę utworzyć aplikację wielowarstwową / warstwową, jakie są najlepsze praktyki dotyczące MVC?

asp.net-mvc architecture

— Erik Funkenbusch
źródło

Odpowiedzi:

DI jest realizowane w ASP MVC przy użyciu fabryki sterowników. Ta fabryka służy do rozwiązywania zależności kontrolera.

MvcContrib ma kilka implementacji Facetry Controller, z których można korzystać od razu po wyjęciu z pudełka. Używam ich implementacji Castle Windsor i działa dobrze. Sugerowałbym również sprawdzenie ich klasy TestHelper. Ma bardzo fajną funkcjonalność do kpienia z kontrolera HTTPContext, sesji itp. MVCContrib

Osobiście lubię nadawać moim modelom instancję repozytorium do pracy. Model udostępnia interfejs API do repozytorium (CRUD). Zależność sterownika od konkretnego modelu jest wstrzykiwana podczas tworzenia (konstruktora), która jest wstrzykiwana za pośrednictwem fabryki sterowników. To jest mój punkt wejścia do wykresu obiektowego, którym zarządza mój kontener IoC.

Gdzie na przykład umieścilibyśmy klasy Repozytorium?

Należą do modelu; są modelem w aplikacji.

Jak zbudować warstwy? Jeśli chcę utworzyć aplikację wielowarstwową / warstwową, jakie są najlepsze praktyki dotyczące MVC?

Warstwy Reprezentują fizyczne separacje kodu. Warstwy reprezentują logiczne separacje. Warstwy (jak są obecnie) działają dobrze dla MVC. W zależności od ilości logiki biznesowej może być ona umieszczona w kontrolerze lub może być umieszczona w osobnym zestawie i może być używana przez kontroler podczas cyklu żądania.

— George Stocker
źródło

Więc sugerujesz, że powinni przejść do projektu interfejsu użytkownika aplikacji wielowarstwowej?

— Erik Funkenbusch

@Mystere Man Jeśli to nie jest gigantyczne, powinni wziąć udział w projekcie, który obsługuje twoją aplikację MVC. W szczególności logika biznesowa trafiłaby do kontrolera, a każda akcja miałaby swoją własną logikę. MVC to nie tylko wzorzec interfejsu użytkownika; dlatego nie zgadzam się z twoim twierdzeniem, że jest to „projekt interfejsu użytkownika”. To nie jest Jest to projekt MVC, który jako Viewsekcja (jest twój interfejs użytkownika).

— George Stocker

Ok, może źle to sformułowałem. Czy nie zgadzasz się jednak, że warstwa widoku nie powinna manipulować bazą danych? A jeśli umieścisz klasy Repozytorium w modelu, widok może to zrobić.

— Erik Funkenbusch

w małej aplikacji MVC „Warstwa” interfejsu użytkownika jest po prostu folderem, który przechowuje widoki. W większej aplikacji może to być własny projekt. Jeśli jest to jego własny projekt, koordynowałby z kontrolerem, a kontroler mógłby w razie potrzeby podłączyć się do BusinessLayer. Nikt poza administratorem nie musiałby nawet wiedzieć, że istnieje warstwa biznesowa. Myślę, że automatycznie myślisz, że są to osobne projekty, ale nie muszą tak być.

— George Stocker,