Korzystałem z takiego rozwiązania. Tworzyłem system w MVC, który składał się z dużych modułów, które mogły działać jako osobne, autonomiczne aplikacje.
Te moduły (pojedynczy projekt zawierający kontrolery,widoki, modele oraz obrazy,skrypty,pliki css) kompilowane były kolejno do pojedynczych plików DLL.
Generalnie plusy:
- wszystko w jednym assembly
- wygodny zarówno logiczny jak i fizyczny podział modułów
- łatwe publikowanie nowych wersji - po prostu zamiana DLLki
- niczego nie zgubisz
- możliwość komunikacji pomiędzy 'modułami'.
Minusy:
- Największy wg mnie minus: każda nowa zmiana napisana w widoku, czy też pliku statycznym(jeżeli również je pakujemy do DLL) wymaga rekompilacji projektu w celu obserwowania zmian - oczywista sprawa.
- Konieczne różne 'obejścia' w wybranych przypadkach, jak urle, dostępy do plików (napisanie własnych helperów) - MVC jednak domyślnie zakłada, że masz fizycznie odróżnione kontrolery, widoki i pliki statyczne.
- Powolne ładowanie plików statycznych (dobranie się do pliku statycznego to defacto osobna akcja na kontrolerze wyodrębniająca wymagany strumień bajtów reprezentujący ten plik z assembly)
Generalnie jak chcesz robić takie rozwiązanie samemu - to piszesz własny ViewEngine - tak jak zrobiono to np. w NopCommerce, gdzie pluginy do oddzielne DLLki.
Ja korzystałem z rozwiązania określanego "portable areas" oferowanego przez bibliotekę MvcContrib. Polecam tą bibliotekę, również dlatego, że ma szereg ulepszeń, helperów przydatnych przy tworzeniu aplikacji w MVC, w tym również przy tworzeniu aplikacji z użyciem portable areas.