Bewährte Vorgehensweise zum Ändern von Standard-Blueprint-Aktionen in sails.js

9

Ich bin auf der Suche nach einer Antwort auf die beste Vorgehensweise, um die standardmäßigen CRUD-Blaupausen von sails.js anzupassen. Das einfache Beispiel dessen, was ich meine, ist, dass ich SomeModel mit der Standard-Blueprint POST \someModel -Aktion erstellen muss. Außerdem möchte ich Informationen über den authentifizierten Benutzer von req object erhalten und diese Eigenschaft auf req.body setzen Verwenden Sie values.user.id in beforeCreate function:

%Vor%

Ich bin sehr neu bei sails.js und möchte keine Anti-Patterns verwenden, also frage ich nach Inputs, wie man solche Fälle richtig behandelt. Auch wäre es gut, einige gute Ressourcen zu diesem Thema zu haben.

    
dim0_0n 21.02.2016, 19:08
quelle

1 Antwort

2

Ihnen stehen einige Optionen zur Verfügung, die Sie identifiziert haben. Wie üblich hängt dies von Ihrem Anwendungsfall ab. Hier sind einige Gedanken zu den drei Optionen, die Sie in Ihrem Kommentar aufgelistet haben:

  1. Override controller/create - Von den drei ist dies die beste Option, da der Code in routes oder policies für eine einzelne Instanz nicht verstopft wird.
  2. Schreibe controller/action und füge zu config/routes.js hinzu - Während dies funktioniert, wird der Zweck der Verwendung von Blueprints vereitelt, und du musst den ganzen Code in Option 1 machen und deinen routes Code unordentlicher machen.
  3. Wenden Sie eine Richtlinie für eine einzelne create -Aktion an - Dazu müssen Sie nicht nur Ihren /policies -Ordner, sondern auch Ihre policies.js -Datei durcheinander bringen. Dies ist mehr Code UND es stellt die Logik für eine Controller-Methode an zwei verschiedenen Stellen, von denen keiner der Controller ist.

Von diesen drei ist Option 1 die beste, weil sie den Code für ihren Kontext (den Controller) enthält und den geschriebenen Code minimiert. Dies setzt voraus, dass Sie nur die Methode create für ein Modell ändern möchten.

Seitliche Anmerkung:

Als Beispiel, wie Ihr Use Case Ihre Implementierung bestimmt, habe ich meine Sails-App eingerichtet, die einige REST-Routen hat, von denen jede unterschiedlich reagiert, je nachdem, welcher Benutzer die Route aufruft (mit einem gültigen Facebook-Account) Token):

  1. Verwendet nur Blueprint-Aktionsrouten (keine Blueprint-REST-Routen)
  2. Zuerst geht es durch die Richtlinien: '*': ['hasFBToken', 'isTokenForMyApp', 'extractFBUser', 'extractMyAppUser'] , die speichern fbuser , myappuser und andere Variablen in req.body
  3. Zu diesem Zeitpunkt wird meine Controller-Funktion (z. B. controller.action() ) aufgerufen und kann auf Informationen über diesen Benutzer zugreifen und feststellen, ob er die richtigen Berechtigungen für CRUD hat.

Vorteile dieses Systems:

  • Der gesamte Code für jede CRUD-Operation ist in der Controller-Funktion
  • enthalten
  • Minimal bis kein Code in routes.js (kein Code) oder policies.js (eine Zeile) oder /policies
  • Funktioniert gut mit API Versioning (z. B. controllers/v1.0/controller.js ), was mit versionierten Controllern viel einfacher ist als mit versionierten Modellen. Das bedeutet, dass ich eine neue API-Version erstellen kann, und indem ich einfach einen Controller in /v2.0 mit einer Funktion action() erstelle, werden Aufrufe wie POST /v2.0/controller/action ohne zusätzliches Routing benötigt.

Ich hoffe, dieses Beispiel zeigt, wie Designentscheidungen getroffen wurden, um Funktionen wie API-Versionierung anzubieten und Code in seinem spezifischen Kontext zu konsolidieren.

    
smileham 24.02.2016, 22:10
quelle

Tags und Links