nicht angemeldet
Tach!
Ich hatte diese Idee auch schon, aber bereits nach kurzer Zeit verworfen, weil das mit einer ganzen Reihe von Nachteilen verbunden ist, den dynamischen Teil einer Route in einer statischen Routingtabelle unterzubringen. Unter Anderem erschwert es die Fehlersuche (was wir ja hier mitkriegen), es vergrößert die Routingtable und es bedingt mehr Code der kompiliert im Speicher vorzuhalten ist.
Die Default-Routing-Tabelle bei ASP.NET MVC besteht aus genau einem Eintrag. Das Muster ist {controller}/{action}/{id}, alle drei Parameter sind optional, es gibt Default-Werte für controller (=Home) und action (=Index). Für den API-Teil gibt es eine zweite Regel bei dem das gleiche Muster mit einem api/ am Anfang verwendet wird. Wenn man sich an diese Konvention hält, also keine abweichende URL-Gestaltung benötigt, wächst da gar nichts.
Für die erschwerte Fehlersuche sehe ich eher ausbaufähiges Wissen um die Debugmöglichkeiten und der Arbeitsweise sowie Verwendung der eingesetzten Teile des Frameworks als das Problem an, zuzüglich der Stolperstellen, wie die von Rolf b genannte, und die kleinen Inkonsistenzen zwischen den Controllern für die HTML-Webseiten und denen für die Web-API. Die sind aber auch teilweise dessen geschuldet, dass die allgemeinen Anforderungen etwas unterschiedlich sind. Für das "normale" Web braucht es eindeutige URLs, API-Zugriffe für CRUD-Operationen hingegen können sich eine URL (pro Thema/Model) teilen und unterschiedliche Requestmethoden verwenden.
Im legacy/native CGI-Modus sind da die Grenzen schnell erreicht wenn bei jedem Request die Routingtable neu in den Speicher geladen wird und jedesmal Unmengen Code zu kompilieren sind, auch Code von Klassen die am eigentlichen Request gar nicht beteiligt sind.
ASP.NET-Anwendungen laufen in so etwas ähnlichem wie dem FastCGI-Modus. Die Anwendung läuft in einem Application-Pool, und wird nur gelegentlich komplett neu gestartet.
Von der allgemeinen 'Klassenflut' ganz zu schweigen und warum sollte sich der URL ändern nur wenn sich die Requestmethode ändert, das Modell und oft auch das View jedoch dasselbe bleibt...
Das ist ja hier auch nicht der Fall. Er hatte, aus welchem Grund auch immer, dieselbe Requestmethode für alle datenändernden CRUD-Aktionen verwendet, und da braucht es eine anderweitige Unterscheidung, wie anders benannte URLs. Ansonsten ist es im Web-API-Teil Usus, dieselbe URL mit unterschiedlichen Requestmethoden zu verwenden. Es entstand dadurch auch keine Klassenflut, es spielte sich für dieses Model alles in derselben Controller-Klasse ab.
dedlfix.
TS
Rolf b