Angenommen, ich habe einen Controller, der eine Liste von Benutzern zurückgibt. Die Benutzer sollen von Memcache zurückgegeben werden, wenn der Cacheschlüssel existiert, andernfalls die mysql db treffen. Diese Logik wird beispielsweise in einer Web-Service-Schicht oder ähnlichem wiederverwendet.
Aktion:
%Vor%In der Java-Welt würden Sie eine UserService-Schicht erstellen, die zusätzliche Logik umschließt (wie zum Beispiel zuerst die Cache-Schicht usw.).
In Schienen neigen Leute dazu, all diese Logik in den Controller zu legen.
Was ist die beste Praxis der Rails hier?
Der "Rails-Weg" ist: dünne Regler, dicke Modelle.
Sie können das Modell einfach so ändern, dass es den Cache unterstützt:
%Vor%Oder erstellen Sie einen Injektor, um den Cache nach Belieben für mehrere Modelle zu unterstützen:
%Vor%Denken Sie daran: Ruby ist als dynamische Sprache sehr einfach zu erweitern. Mixins, Interzeptoren, Aspekte, all diese Dinge, die ein PITA in Java zu implementieren sind, sind auf Ruby sehr einfach und natürlich. Probieren Sie es aus.
Es scheint eine "kleine" Bewegung in der Rails-Community zu geben, eine Service-Schicht in einigen Projekten / Anwendungen zu etablieren. Im Jahr 2010 arbeitete ich an einem Projekt, bei dem wir ein Apps / Services-Verzeichnis zum Speichern von Service-Objekten einführten. Wir fanden heraus, dass die Anwendungslogik über Controller und Modelle verteilt war, was dazu beitrug, ein solches Verhalten einzukapseln. James Golick hat einen interessanten Beitrag zu diesem Thema. Schauen Sie sich auch die Kommentare von Pat Maddox an:
Tags und Links ruby-on-rails