Ich verschiebe Code von einer Anwendung, die in einem nicht standardmäßigen benutzerdefinierten PHP-Framework in Ruby on Rails (Version 3) erstellt wurde. In der PHP-Version sind alle Controller wirklich fett, mit dünnen Modellen, mit denen ich immer nicht einverstanden war, also genieße ich die Art und Weise, wie Rails die Validierung auf Modellebene durchführt, was wahrscheinlich 90% von dem ist, was in diesen fetten Controllern passiert zur Zeit.Rails 3 ActiveRecord Validierung basierend auf Benutzerberechtigungen
Ein Problem, mit dem ich konfrontiert bin, und unsicher, wie man es lösen kann, sind unterschiedliche Validierungsregeln, die darauf basieren, wer die Änderung am Modell vornimmt. Zum Beispiel sollte ein Administrator oder der ursprüngliche Ersteller des Datensatzes in der Lage sein, Dinge zu tun, wie einen Datensatz als gelöscht markieren (soft delete), während dies für alle anderen nicht gilt.
class Something < ActiveRecord::Base
...
validates :deleted, :owned_by_active_user => true
...
end
class OwnedByActiveUserValidator < ActiveModel::EachValidator
validate_each(record, attr_name, attr_value)
# Bad idea to have the model know about things such as sessions?
unless active_user.admin? || active_user.own?(record)
record.errors.add :base, "You do not have permission to delete this record"
end
end
end
Da das Modell selbst (in der Theorie) weiß nichts von dem Benutzer, der die Änderung macht, was ist die „Schienen Weg“ diese Art der Sache zu tun? Sollte ich den aktiven Benutzer als virtuelles Attribut für den Datensatz festlegen (nicht tatsächlich in DB gespeichert), oder sollte ich diese Prüfungen nur im Controller durchführen? Ich muss zugeben, dass es merkwürdig ist, wenn das Modell Berechtigungen für den aktiven Benutzer überprüft, und es erhöht die Komplexität, wenn es darum geht, das Modell zu testen.
Ein Grund, warum ich so viel wie möglich im Modell behalten möchte, ist, weil ich sowohl eine API (Zugriff über OAuth) als auch eine Website bereitstellen möchte, ohne zu viel Code wie diese zu duplizieren Arten von Berechtigungen überprüft.
Danke, ich muss dir zustimmen. Meine Modelle sollten tun, was ihnen gesagt wird (sofern die Geschäftslogik dies zulässt). Meine Controller sollten entscheiden, wer es ihnen sagt. Ich werde nur sicherstellen, dass ich die blutigen Details so gut wie möglich abstrahiere. – d11wtq
Dogma ... Ich weiß, dass es so üblich ist, aber es scheint mir, dass die direkte Integration von Access Control in die Modelle eine elegante Lösung ist, wenn man die Modelle als Daten-API/Business-Rule-Layer betrachtet. Es vermeidet auch, dieselben Informationen in mehreren Controllern zu wiederholen, die dasselbe Modell berühren.Und die Verwendung von Validatoren für den Zweck scheint auch sehr praktisch - kann Fehler wie "sorry, Sie haben keine Berechtigung, dieses Feld zu bearbeiten" generieren. Dieses Feld sollte jedoch nicht an erster Stelle stehen. Ich wünschte, es gäbe eine Lösung, die es erlaubt, Form Builder zu introspizieren. – odigity
Sie können Formularmodell-Klassen (nicht datenbankgestützt) erstellen, die die Validierung implementieren, und die vom Formular-Generator benötigten Methoden. – yfeldblum