ASP.NET MVC-Routing basierend auf Datenspeicherwerten

8

Wie würden Sie dieses Problem angehen:

Ich habe Daten in meinem Datenspeicher. Jeder Artikel enthält Informationen über:

  • URL = eine beliebige Anzahl erster Routensegmente, die mit Anfragen verwendet werden
  • irgendein Element type = display wird auf diesen Typ bezogen (lesen)
  • title = wird zum Beispiel in der Navigation um meine Anwendung verwendet
  • usw.

Da jedes Element eine beliebige Anzahl von Segmenten haben kann, habe ich eine benutzerdefinierte Route erstellt, mit der ich diese Art von Anfragen bearbeiten kann, ohne die Standardroute zu verwenden und einen einzigen greedy Routenparameter zu haben.

Der Artikeltyp definiert tatsächlich, auf welche Weise der Inhalt eines bestimmten Artikels dem Kunden angezeigt werden soll. Ich dachte daran, genauso viele Controller zu erstellen, um nicht zu viel Code in einer einzigen Controller-Aktion zu haben.

Wie würden Sie das in ASP.NET MVC tun, oder was würden Sie vorschlagen, wäre dies der machbarste Weg?

Bearbeiten: Ein paar weitere Details

Meine Artikel werden in einer Datenbank gespeichert. Da sie sehr unterschiedliche Typen haben können (nicht vererbbar), dachte ich daran, genauso viele Controller zu erstellen. Aber Fragen entstehen:

  1. Wie sollte ich diese Controller für jede Anfrage erstellen, da sie mit einigen dynamischen Daten zusammenhängen? Ich könnte meine eigene Controller-Fabrik oder Route-Handler oder möglicherweise auch andere Erweiterungspunkte erstellen, aber welche wäre am besten?

  2. Ich möchte die MVC-Grundfunktionalität der Verwendung von Dingen wie Html.ActionLink(action, controller, linkText) verwenden oder meine eigene Erweiterung wie Html.ActionLink(itemType, linkText) machen, um sie noch flexibler zu machen. Daher sollte Action Link korrekte Routen basierend auf Routendaten erstellen Was passiert im Hintergrund - es geht durch Routen von oben nach unten und sehen, welche eine resultierende URL zurückgibt).

  3. Ich dachte an eine Konfiguration der Beziehung zwischen itemType und Routenwerten (Controller, Aktion, Standardwerte). Die Standardeinstellungen können schwierig sein, da Standardwerte aus einer Konfigurationszeichenfolge in ein Objekt deserialisiert werden müssen (was ebenfalls komplex sein kann). Also dachte ich mir vielleicht sogar eine konfigurierbare Beziehung zwischen itemType und Klassentyp , die eine bestimmte Schnittstelle implementiert, wie im folgenden Beispiel geschrieben.

  4. Meine Routen können im Datenspeicher geändert (oder einige neue hinzugefügt) werden. Neue Typen sollten jedoch nicht hinzugefügt werden. Die Konfiguration würde diese Szenarien bereitstellen, da sie Typen mit Routenstandardwerten verknüpfen würden.

Beispiel :

Schnittstellendefinition:

%Vor%

Implementierungsbeispiel für die Schnittstelle:

%Vor%

Konfigurationsbeispiel:

%Vor%

Um Leistungseinbußen zu vermeiden, kann ich meine Artikel zwischenspeichern und mit In-Memory-Daten arbeiten und den Zugriff auf die Datenbank bei jeder Anfrage vermeiden. Diese Artikel ändern sich nicht allzu oft. Ich konnte sie für 60 Minuten zwischenspeichern, ohne die Anwendungserfahrung zu beeinträchtigen.

    
Robert Koritnik 23.12.2009, 13:44
quelle

2 Antworten

3

Wenn Sie ein komplexes Routing-Wörterbuch definieren oder nur einen generischen Routing-Eintrag haben und alle Fälle selbst behandeln, gibt es kein signifikantes Leistungsproblem. Code ist Code

Auch wenn Ihre Datentypen nicht vererbbar sind, haben Sie wahrscheinlich gemeinsame Anzeigemuster. z.B.

  • Liste der Titel und Zusammenfassungstext
  • Objektanzeige, mit Titel, Bild, Beschreibung
  • usw.

Wenn Sie Ihre Site in eine endliche Anzahl von Anzeigemustern aufteilen können, müssen Sie nur diese endlichen Controller und Views erstellen

Sie stellen eine Servicesbene bereit, die vom Routing-Parameter ausgewählt wird, und verwendet ein DTO-Muster (Data Transfer Object), um die Falldaten in die Standarddatenstruktur der Ansicht zu übernehmen

    
TFD 12.01.2010, 21:28
quelle
2

Das allgemeine Konzept, das Sie erwähnen, ist nicht ungewöhnlich und es gibt ein paar Dinge zu beachten:

  1. Sobald ich etwas über URL-Routing höre, das von Daten aus einer Datenbank abhängig ist, denke ich zuerst an die Performance. Eine Möglichkeit, potentielle Performance-Probleme zu verringern, ist die Verwendung der eingebauten Route-Klasse und ein sehr allgemeines Muster, beispielsweise "somethingStatic/{*everythingElse}" . Auf diese Weise wird, wenn die URL nicht mit "somethingStatic" beginnt, die Übereinstimmung sofort hergestellt und das Routing wird mit der nächsten Route fortgesetzt. Dann erhalten Sie alle interessanten Daten als Catch-All-Parameter "everythingElse".

  2. Sie können diese Route dann einem benutzerdefinierten Routenhandler zuordnen, der von MvcRouteHandler abgeleitet wird und GetHttpHandler überschreibt, um zur Datenbank zu gehen, den Wert "everythingElse" zu ermitteln und vielleicht dynamisch zu bestimmen, welcher Controller und Aktion sollte verwendet werden, um diese Anfrage zu bearbeiten. Sie können die Routing-Werte erhalten / einstellen, indem Sie auf requestContext.RouteData.Values zugreifen.

  3. Ob ein Controller und eine Aktion oder viele von einem oder mehreren von beiden verwendet werden, ist eine Diskussion für sich. Die Frage läuft darauf hinaus, wie viele verschiedene Arten von Daten Sie haben? Sind sie meistens ähnlich (sie sind alle Bücher, aber einige sind Hardcover und einige sind Softcover)? Ganz anders (manche sind Autos, manche sind Bücher, manche sind Häuser)? Die Antwort darauf sollte dieselbe Antwort sein, die Sie hätten, wenn es sich um eine Computerprogrammierklasse handelte, und Sie mussten aus einer OOP-Perspektive entscheiden, ob sie alle eine Basisklasse und ihre eigenen Ableitetypen haben oder ob sie leicht durch dargestellt werden können ein gemeinsamer Typ. Wenn sie alle verschiedene Typen sind, würde ich verschiedene Controller empfehlen - vor allem, wenn jeder eine bestimmte Menge von Aktionen erfordert. Für ein Haus möchten Sie beispielsweise einen Inspektionsbericht sehen. Aber für ein Buch möchten Sie vielleicht die ersten fünf Seiten ansehen und eine Buchbesprechung lesen. Diese Elemente haben nichts gemeinsam: Die Aktionen für die eine würden nie für die andere verwendet werden.

  4. Das in # 3 beschriebene Problem kann auch umgekehrt auftreten: Was passiert, wenn Sie 1000 verschiedene Objekttypen haben? Willst du 1000 verschiedene Controller? Ohne weitere Informationen würde ich sagen, dass 1000 Controller für dieses Szenario ein bisschen zu viel sind.

Hoffentlich helfen Ihnen diese Gedanken, die richtige Lösung zu finden. Wenn Sie weitere Informationen zu bestimmten Szenarien zur Verfügung stellen können (z. B. welche Arten von Objekten diese sind und welche Aktionen auf sie angewendet werden können), kann die Antwort ebenfalls verfeinert werden.

    
Eilon 30.12.2009 20:23
quelle