2009-10-07 15 views
32

Ich dachte über Beobachter oder Rückrufe. Was und wann sollten Sie einen Beobachter verwenden?Beobachter und Rückrufe

F.e. Folgende Sie tun können:

# User-model 
class User << AR 
    after_create :send_greeting! 

    def send_greeting! 
    UserNotifier.deliver_greeting_message(self) 
    end 

end 

#observer 
class UserNotifier << AR 
    def greeting_message(user) 
    ... 
    end 
end 

oder Sie können einen Beobachter erstellen und lassen Sie es sehen, wenn Benutzer erstellt wird ...

Was Dou Sie recommened?

Antwort

9

Ein Rückruf ist kurzlebiger: Sie übergeben ihn in eine Funktion, die einmal aufgerufen werden soll. Es ist Teil der API, dass Sie die Funktion normalerweise nicht aufrufen können, ohne auch einen Rückruf zu übergeben. Dieses Konzept ist eng mit dem gekoppelt, was die Funktion tut. In der Regel können Sie nur einen einzelnen Callback übergeben.

Beispiel: Einen Thread ausführen und einen Rückruf geben, der beim Beenden des Threads aufgerufen wird.

Ein Beobachter lebt länger und kann jederzeit angeschlossen/gelöst werden. Es kann viele Beobachter für dasselbe geben und sie können unterschiedliche Lebensdauern haben.

Beispiel: Anzeigen von Werten aus einem Modell in einer Benutzeroberfläche und Aktualisieren des Modells aus Benutzereingaben.

27

Sie können Beobachter als Mittel zur Entkopplung oder Verteilung von Verantwortlichkeiten verwenden. Im elementaren Sinne - wenn Ihr Modellcode zu unordentlich wird, sollten Sie darüber nachdenken, Beobachter für ein unwesentliches Verhalten zu verwenden. Die wirkliche Macht (zumindest, wie ich es sehe) der Beobachter liegt in ihrer Fähigkeit, als Verbindungspunkt zwischen Ihren Modellen und einem anderen Subsystem zu dienen, dessen Funktionalität von allen (oder einigen) der anderen Klassen genutzt wird. Angenommen, Sie möchten eine IM-Benachrichtigung zu Ihrer Anwendung hinzufügen, z. B. wenn Sie über einige (oder alle) der CRUD-Aktionen einiger (oder aller) Modelle in Ihrem System benachrichtigt werden möchten. In diesem Fall wäre die Verwendung von Beobachtern ideal - Ihr Benachrichtigungs-Subsystem bleibt perfekt von Ihrer Geschäftslogik getrennt und Ihre Modelle werden nicht mit einem Verhalten belastet, das sie nicht betrifft. Ein weiterer nützlicher Anwendungsfall für Beobachter wäre ein Teilsystem der Rechnungsprüfung.

41

Eine wirklich wichtige Unterscheidung, die mit Milan Novotas Antwort verbunden ist, ist, dass Callbacks auf einem ActiveRecord die Möglichkeit haben, die aufgerufene Aktion und alle nachfolgenden Callbacks zu stornieren, wo Beobachter dies nicht tun.

Beobachter dürfen nur beobachten, sie dürfen nicht eingreifen.

+19

Dies ist nicht mehr der Fall in Schienen 3.1 Beobachter können die Aktion einer Speicherung durch die Rückgabe von false aus der before_ * stornieren, die die Aktion abbrechen und eine Ausnahme in after_ * auslösen kann, um die Aktion ausnahmsweise zu stornieren. –

+0

Dank Jrizza, hatte ich einen ähnlichen Fall, in dem ein Fehler in einem der Beobachter die Aufzeichnung nicht zu speichern verursacht, was ich denke, ist ein unerwünschtes Ergebnis. –

+2

Ja, es ist merkwürdig, sie sind keine Beobachter mehr, eine Ausnahme in einem Beobachter wird dazu führen, dass die Festschreibung fehlschlägt und der Benutzer einen Ausnahmebildschirm erhält. Für mich ergibt das keinen Sinn. – Amala