ASP MVC Ajax Controller Muster?

Question

Meine MVC-App neigt dazu, viele Ajax-Aufrufe zu haben (via JQuery.get()). Es nervt mich, dass mein Controller mit vielen kleinen Methoden übersät ist, die über Ajax aufgerufen werden. Es scheint mir, eine Art brechen die MVC-Muster ein bisschen - der Controller ist jetzt mehr eine Datenzugriffskomponente als ein URI-Router.

Ich refaktoriert, so dass ich meine "wahre" Controller für eine Seite nur Durchführung von Standard-Routing-Antworten (Wiedergeben ActionResponse-Objekte). Ein Aufruf von/home/wird also die HomeController-Klasse anstoßen, die in der kanonischen Controller-Art antworten wird, indem sie eine Plain-Jane-View zurückgibt.

Ich habe dann meine Ajax-Sachen in eine neue Controller-Klasse verschoben, deren Namen ich mit 'Ajax' vorstelle. So könnte meine Seite beispielsweise drei verschiedene Funktionsbereiche haben (zB Warenkorb oder Benutzerkonto). Ich habe einen Ajax-Controller für jeden von ihnen (AjaxCartController, AjaxAccountController). Es gibt wirklich nichts anderes, als die Ajax-Anruf-Sachen in eine eigene Controller-Klasse zu verschieben - es ist nur, um die Dinge sauberer zu halten. offensichtlich auf Client-Seite der JQuery würden dann diese neuen Controller thusly verwenden:

//jquery pseudocode call to specific controller that just handles ajax calls 
$.get('AjaxAccount/Details'.... 

(1) ist es ein besseres Muster in MVC zu Ajax-Aufrufen reagiert?

(2) Es scheint mir, dass das MVC-Modell ein wenig undicht ist, wenn es um Ajax geht - es ist nicht wirklich "Controlling" Zeug. Es ist zufällig die beste und am wenigsten schmerzhafte Art, Ajax-Anrufe zu bearbeiten (oder bin ich ignorant)?

Mit anderen Worten, die 'Controller' Abstraktion scheint nicht nett zu spielen mit Ajax (zumindest aus einer Perspektive Muster). Gibt es etwas, das mir fehlt?

Answer 1

Während Sie Controller am Ende es ausdrückte könnten ASP.NET MVC Routing Magie Arbeit zu machen, neige ich dazu, zu tun, was Sie bereits getan haben - außer wenn ich AjaxCartController las ich ich denke AjaxCartPresenter (als im Model-View-Presenter-Muster, das normalerweise in WinForms zu sehen ist). Das heißt, dieser "Controller" steuert nicht, sondern ist unverhohlen an die View-Schnittstelle gebunden. Aber im Gegensatz zur Ansicht ist der Controller Presenter testbar.

Wenn wir eine Webseite AJAXify machen, verwandeln wir sie in etwas, das in einer feinkörnigen Art und Weise reagieren kann, so dass feinkörnige Methoden in Ordnung sind. Feinkörnigkeit ist der Punkt und der ganze Grund, warum es erfunden wurde. Wir gehen absichtlich von REST für ein bestimmtes Szenario weg, weil dieses spezielle Muster die UI-Anforderungen nicht löst, sondern stattdessen ein RPC-ähnliches Modell auswählt. Sie sind nur Muster, eines wird nicht besser sein als das andere in allen Situationen, auch wenn unser Technologie-Stack uns zu einem über den anderen drängen könnte. (In der Tat, HTTP selbst ist besser in Chunks/Seiten/Entitäten/Repräsentation staatlichen Transfer-Dokumente.)

Mental können Sie diese Seiten behandeln, als ob sie Formulare in einer WinForms-Anwendung waren; Die Tatsache, dass diese Methoden in einem "Controller" sitzen, ist nur ein Artefakt und Zugeständnis gegenüber der verwendeten Technologie.(Wenn es dich super stört, könntest du die AJAX-Methoden in eine IHttpHandler rollen und MVC ganz umgehen, aber warum wegwerfen die automatische Routing/Instanziierung/Methoden-Suche und mach es dir schwer? Es wäre architektonisch 'sauber' und rein, aber von zweifelhaftem Nutzen.)

... zumindest, das ist, wie ich es mir =) zu helfen

Answer 2

Wenn Sie zu viele feinkörnige Anfragen haben, möchten Sie vielleicht eine Controller-Aktionsmethode für alle Anrufe haben. Sie können einen 'Schalter' in der Methode verwenden, um den Anruftyp zu bestimmen und ihn entsprechend zu bedienen, anstatt eine Unmenge winziger Methoden zu verwenden. Sie könnten sogar explizite String-Konstanten anstelle von Zahlen für die Switch-Variable verwenden.