Tach!
Wenn es für einen Controller, ein Model, einen View zu komplex wird, ist es an der Zeit aufzuteilen. Subcontroller, strukturierte Models, Teil-Views.
Und auch Dinge außerhalb des MVC-Patterns. Services bieten sich an, konkrete Aufgaben zu erledigen, die sich aus dem Anwendungsfall ergeben, die zu viel sind für einen Controller oder die von mehreren Stellen aus angesprochen werden müssen. Die arbeiten dann nach oben hin mit wem auch immer, der die Dienste braucht zusammen und nach unten hin mit dem Model oder anderen Datenquellen.
Ich verweise an der Stelle mal auf ein Application Framework namens "ASP.NET Boilerplate". Das ist zwar in C# geschrieben und im Hinblick auf die Belange und Notwendigkeiten im "ASP.NET MVC"-Ökosystem. Doch für das Thema hier sind eher Teile von dessen Dokumentation interessant. Im Speziellen meine ich da die Seite zur NLayer Architecture.
Dazu ein großes Aber: In dem Framework sind zwar jede Menge Dinge drin, die man recht häufig in vielen Projekten finden kann. Aber nicht alles braucht man überall. Die dort gezeigte Komplexität in voller Schönheit lohnt sich erst ab bestimmten Projektgrößen. Bei kleineren kann man durchaus Abkürzungen nehmen. So eine Architektur ist ja kein Gesetz sondern nur ein Vorschlag und man darf die Dinge auch anders sehen und implementieren.
dedlfix.