Struktura projektu MVC 3

Question

Próbuję znaleźć najlepszy sposób na zaprojektowanie mojego projektu MVC 3. Podczas wyszukiwania w Internecie natknąłem się na sugestię, która zasadniczo mówi prawy klik na projekcie i dodaje obszar. W tym celu utworzono folder obszaru o tej samej strukturze kontrolera/widoku/modelu w tym samym projekcie. Nie tego chcę. Chcę elastyczności posiadania oddzielnych projektów. Zachowam tylko widoki w głównym projekcie internetowym. Wszystko inne w osobnym projekcie.

W ramach tej próby utworzyłem osobny projekt dla moich kontrolerów. Teraz utknąłem, wskazując działanie kontrolera na widok. We wszystkich przykładach online kliknięcie prawym przyciskiem myszy i dodanie widoku. Ponieważ jest to projekt biblioteki klasowej, nie mam takiej elastyczności. Gdzie się mylę?

Wszystkie przykłady, które znalazłem, w tym te, które przeszły przez Asp.net, w zasadzie wyjaśniają, jak tworzyć aplikacje do nauki, które są dobre tylko do celów edukacyjnych. Duża aplikacja komercyjna nie może mieć wszystkich widoków/modeli/kontrolerów w jednym projekcie. Czy jest to sposób, w jaki powinien przejść w MVC? Nie jestem pewien, czy robienie wszystkiego za pomocą kliknięć myszy jest również dobrym pomysłem. W świecie webformów było też wiele aplikacji dla początkujących, które używały kliknięć myszką do tworzenia podstawowych aplikacji CRUD, ale w prawdziwych komercyjnych projektach nigdy nie korzystaliśmy z tych metod.

Jakie są twoje myśli, wskazówki na ten temat?

Dzięki za poświęcony czas ...

Answer 1

MVC opiera się na konwencji; Konwencja polega na umieszczeniu wszystkich widoków na/widokach, modelach w/modelach i kontrolerach w/kontrolerach. Możesz zmienić konwencję, ale nie ułatwi ci to życia.

Z koncepcyjnego punktu widzenia ma to sens. Jeśli zachowasz całą logikę domeny i dostęp do danych w oddzielnych projektach, pozostaniesz z materiałami związanymi z siecią, kontrolerami, widokami modeli i widokami. To twój projekt MVC.

Pamiętaj, że jeśli chcesz podzielić się części w oddzielnych projektów można znaleźć portable areas użyteczne.

Answer 2

ja nie rozumiem, dlaczego nie można użyć wbudowanego w generatorach jako bazę dla swoich poglądów i kontrolerów? Nic nie mówi, że musisz zostawić je jako wygenerowane. Osobiście uważam, że to jest naprawdę fajne, aby uzyskać wygenerowaną dla mnie bazę (za pomocą kliknięć myszką).

Projekt MVC to tylko warstwa interfejsu użytkownika. Szaleństwem jest umieszczanie w nim logiki dla aplikacji na dużą skalę. Dlatego zwykle dobrze jest mieć jeden projekt dla całego interfejsu użytkownika. Dzięki temu łatwiej uzyskać ogólny przegląd interfejsu użytkownika.

Powiedziawszy, istnieją sposoby uzyskania rozwiązania opartego na wtyczce, w którym można przenosić kontrolery (modele i widoki) do bibliotek klas. Ale to nie jest łatwe.

1. Musisz stworzyć wirtualny dostawcy ścieżki (aby odnaleźć poglądy)
2. Dodać wszystkie widoki osadzone
3. zmodyfikować plik projektu, aby uzyskać „Dodaj widok” dialogowe itp
4. Stosować obszary (ułatwia to)
5. Powiedz BuildManager, że istnieje plik DLL wtyczki.

też trzeba zmodyfikować ścieżkę wirtualną do dostawcy dostępu widoki z wtyczki folderów, jeśli chcesz być w stanie zmienić poglądy podczas wykonywania w visual studio. Każda zmiana wymagałaby przebudowania biblioteki DLL wtyczki.

Aktualizacja

Video dla MVC2 (obszary MVC3 działa tak samo): http://www.asp.net/mvc/videos/mvc-2/how-do-i/aspnet-mvc-2-areas

Należy pamiętać, że ten film jest dla obszarów w tym samym projekcie. Posiadanie obszarów w oddzielnych bibliotekach klas jest bardziej złożone. Najłatwiejszym rozwiązaniem jest korzystanie z przenośnych obszarów sugerowanych przez kogoś innego.

Answer 3

Dlaczego zachować tylko swoje poglądy w „głównym projektu internetowej” - myślę, że brakuje punktu z MVC.

To kontrolery, które są twoją "główną stroną". Są tym, czego żądają użytkownicy i którzy je przesyłają, a nie widokiem.

Widok jest tylko tam, aby zapewnić środki do układu HTML dla kontroler pchnąć do przeglądarki.

Modele, które moim zdaniem powinny być modelami ViewModels, mają na celu przedstawienie substancji (tj. Prawdziwych danych) dla Państwa poglądów.

Więc widać, że układ MVC naprawdę chce wszystkie trzy z nich mają być pogrupowane sensownie ze sobą. Kontrolery współdziałają z Twoim użytkownikiem, pobierają widok (układ) i wypełniają go swoim ViewModel/Model (dane). To jest twój interfejs użytkownika, wszystkie trzy części MVC (jeśli pójdziesz z ViewModel tak czy inaczej) są tylko dla interfejsu użytkownika.

Skąd pochodzą dane, twoje prawdziwe modele i cokolwiek chcesz z tym zrobić, mogą z łatwością znajdować się w bibliotece DLL gdzieś lub po drugiej stronie zestawu usług sieciowych lub czegoś podobnego.