nicht angemeldet
Rolf b...in einer statischen Routingtabelle...
Die ASP.NET MVC Designer verwenden das Prinzip "Convention before Configuration", d.h. wenn Du eine URL verwendest, die auf das von dedlfix genannte allgemeine Muster passt, dann sucht die MVC Runtime nach einer Klasse mit passendem Namen, instanziiert sie und ruft darin dann eine entsprechende Action Methode auf. Bei Web-API baut er ggf. noch das HTTP-Verb mit ein, um den Methodennamen abzuleiten.
Solange man die Convention kennt, und sie auch zum Problem passt, ist das alles schnuckelig und kompakt abbildbar. Was die MVC Runtime im Hintergrund treibt, ist eine andere Frage, er wird z.B. nicht jedesmal alle geladenen Assemblies nach Controllern durchflöhen, sondern das nur einmal tun und in einem Dictionary cachen.
...es vergrößert die Routingtable und es bedingt mehr Code der kompiliert im Speicher vorzuhalten ist.
Das ist letztlich richtig; das Routing, das ich konfiguriere, ist nur die Spitze des Vanilleeisberges und die eigentliche Routingtable baut MVC im Cache auf. Aber eben nur einmal. ASP.NET läuft im IIS als Application bzw. unter Apache und Mono als Apache-Modul, d.h. da wird einmal der Code geladen und verarbeitet dann die einlaufenden Requeste. Das muss man natürlich beim Programmieren beachten, man kann nicht einfach so mit static-Variablen herummachen. Die werden von allen parallel laufenden Requests geteilt. Ein Reload der Application (bzw. Recycle des Application Pool) findet statt, wenn ASP.NET eine Änderung der web.config oder der zur Application gehörigen Ressourcen erkennt, oder nach einer gewissen Zeitdauer (Reboot tut gut). Das merkt man genau - der erste Aufruf eines ASP.NET Service dauert sehr lange, der Rest geht fix.
Von der allgemeinen 'Klassenflut' ganz zu schweigen
Das kann man so und so sehen. Klassen sollen im Sinne von SRP eh nicht groß sein, von daher entstehen bei Beachtung der Clean Code Prinzipien ohnehin eine Menge davon.
Gruß vom Baggersee 😉
Das ist ein GUTER Plan. Verbrenne Dich nicht!
Rolf
TS