Struktura projektu ASP.NET MVC dla większych witryn

Question

Jestem zaskoczony, że nie mogę znaleźć więcej dyskusji na temat problemu, który naprawdę przeszkadza mi w naszym projekcie przy użyciu ASP.NET MVC.

Jak radzić sobie z rozwiązaniem Visual Studio, które ma wiele projektów? Struktura MVC ma folder Modele/Widoki/Kontrolery w głównym projekcie. Ale co jeśli chcesz podzielić swoje rozwiązanie na wiele projektów według logicznych grupowań i przynieść ze sobą modele/widoki/kontrolery? Kiedy myślę o przyszłości do końca projektu, w każdym z tych folderów będzie wiele klas. Nie maluje uporządkowanej struktury, która ułatwi utrzymanie. Chcielibyśmy albo przenieść klasy do projektów, do których się odnoszą, albo przynajmniej użyć struktury folderów do pomocy w organizacji.

Zakładam, że jedną opcją byłoby użycie tej samej przestrzeni nazw we wszystkich innych projektach, jaka jest używana w głównym projekcie, ale nie jestem wielkim fanem tego podejścia b/c, to nie jest podejście, które zwykle robiliśmy to podczas definiowania naszej przestrzeni nazw.

Przypuszczam, że moglibyśmy przynajmniej utworzyć podfoldery wewnątrz folderów M/V/C i nie przenosić nazw folderów do przestrzeni nazw. Zakładam, że można było znaleźć klasy?

Niektóre informacje o naszym projekcie: Jest to strona internetowa, która ma wiele transakcji biznesowych, które użytkownik może wykonać (około 50-60). Każda transakcja ma szereg stron internetowych, przez które przechodzi użytkownik, w celu realizacji różnych usług świadczonych przez witrynę. Używamy pojedynczego kontrolera dla każdej transakcji (od dłuższego czasu trwa dyskusja, czy powinniśmy mieć zdefiniowanego kontrolera dla każdej transakcji, czy też powinniśmy użyć grupowania wyższego poziomu, a tym samym zmniejszyć liczbę kontrolerów, ale pewne informacje, które mamy napotkane w Internecie (http://codebetter.com/blogs/ian_cooper/archive/2008/12/03/the-fat-controller.aspx) doprowadziły nas do tej decyzji.)

Jakie są niektóre zalecenia? Czy inni rozwiązali ten problem w sposób, z którego są zadowoleni?

Dzięki Jon.

Answer 1

Spójrz na Areas.

Obszary to koncepcja zapożyczona z MonoRail, która organizuje kontrolery w logiczne foldery.

http://haacked.com/archive/2008/11/04/areas-in-aspnetmvc.aspx

Answer 2

zawsze usunąć folder „modele” i odniesienie do oddzielnych bibliotek klas, które reprezentują swoje biznesowych warstwy logiki i warstwy dostępu do danych. Mam też pewne rozwiązania, w których moi kontrolerzy są trzymani w oddzielnych projektach z mojego punktu widzenia. Zgadzam się, że w większych aplikacjach pojedynczy model projektu jest niewłaściwy. Nawet w mniejszych aplikacjach, szczególnie tam, gdzie kod modelu musi być współdzielony z innymi aplikacjami, umieszczanie klas modeli w rzeczywistym projekcie MVC jest złym pomysłem.

Answer 3

Obszary są obsługiwane w Asp.Net MVC2.

Scott Gu ma bloga mówiącego o Area Support here.

Ze swojego posta.

Każdy obszar może być realizowany jako oddzielny projekt ASP.NET MVC, które mogą być następnie odwołuje głównego aplikacji.To pomaga zarządzać złożoność przy budowie dużej aplikację oraz ułatwia pracę wielu zespołów razem na jednej stosowania razem