Solutions de rechange de rails observateur pour 4.0

Question

Avec les Observateurs officiellement obsolète dans les Rails 4.0, je suis curieux de savoir ce que les autres développeurs utilisent à leur place. (Autres que l'aide de l'extrait du gem.) Alors que les Observateurs ont certainement été abusé et pourrait facilement devenir unwieldily à la fois, il y avait de nombreux cas d'utilisation en dehors de la juste cache-clairière où ils ont été bénéfiques.

Prenez, par exemple, une application qui a besoin de suivre les modifications apportées à un modèle. Un Observateur pourrait facilement surveiller les modifications sur Un Modèle et d'enregistrer ces modifications avec le Modèle B dans la base de données. Si vous voulais regarder pour les changements à l'échelle de plusieurs modèles, un seul observateur pourrait gérer cela.

Dans les Rails 4, je suis curieux de savoir quelles sont les stratégies des autres développeurs utilisent à la place des Observateurs de recréer cette fonctionnalité.

Personnellement, je penche vers une sorte de "fat controller" mise en oeuvre, lorsque ces modifications sont suivies dans chacun des modèles du contrôleur de créer/mettre à jour/supprimer la méthode. Alors qu'il gonfle le comportement de chaque contrôleur légèrement, il ne aider à la lisibilité et à la compréhension que tout le code est dans un seul endroit. L'inconvénient, c'est qu'il y a maintenant le code qui est très similaire dispersées dans plusieurs contrôleurs. L'extraction de ce code dans les méthodes d'aide est une option, mais vous êtes toujours à gauche avec les appels à ces méthodes jonché partout. Pas la fin du monde, mais pas tout à fait dans l'esprit de "skinny contrôleurs".

ActiveRecord rappels sont une autre option possible, mais un je ne suis pas personnellement aime, comme il tend à quelques deux modèles différents de trop près, ensemble, à mon avis.

Donc dans les Rails 4, no Observateurs monde, si vous aviez à créer un nouvel enregistrement après un autre record a été créé/mise à jour/détruit, ce modèle de conception utiliseriez-vous? La graisse des contrôleurs, ActiveRecord rappels, ou tout autre chose?

Je vous remercie.

Answer 1

Jetez un oeil à des préoccupations

Créez un dossier dans votre répertoire de modèles appelé préoccupations. Ajouter un module là :

Ensuite, inclure dans les modèles que vous souhaitez exécuter l’after_save :

Selon ce que vous faites, cela pourrait recevoir vous fermez sans observateurs.

Answer 2

Ils sont maintenant dans un plugin .

Je peux également recommander une alternative qui vous donnera les contrôleurs comme :

Answer 3

Ma suggestion est de lire James Golick du blog à http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i-write-rails-apps.html (essayez d'ignorer comment les impudiques, le titre sonne).

De retour dans la journée, il était tout "modèle de graisse, skinny contrôleur". Ensuite, les modèles de matières grasses est devenu un géant des maux de tête, surtout pendant les tests. Plus récemment, la poussée a été pour skinny modèles, l'idée étant que chaque classe doit être la manipulation d'une responsabilité et d'un modèle de travail est de persister vos données à une base de données. D'où vient donc de tous mes complexes de la logique métier de la fin? Dans les affaires de la logique de classes: les classes qui représentent les transactions.

Cette approche peut se transformer en un bourbier (giggity) lorsque la logique commence à devenir compliqué. Le concept est son bien -- plutôt que de déclencher des choses implicitement avec des rappels ou des observateurs qui sont difficiles à tester et déboguer, déclencher des choses explicitement dans une classe que les couches de logique sur le dessus de votre modèle.

Answer 4

À l'aide d'active record rappels simplement flips la dépendance de votre attelage. Par exemple, si vous avez modelA et CacheObserver observant modelA de rails 3, de style, vous pouvez supprimer CacheObserver sans problème. Maintenant, au lieu de dire A a à appeler manuellement l' CacheObserver après l'enregistrer, ce qui serait rails 4. Vous avez simplement déplacé votre dépendance de sorte que vous pouvez supprimer en toute sécurité A mais pas CacheObserver.

Maintenant, à partir de ma tour d'ivoire, je préfère l'observateur à être dépendant du modèle d'observation. Dois-je prendre soin assez pour éviter d'encombrer mon contrôleurs? Pour moi, la réponse est non.

Je suppose que vous avez mis une certaine pensée dans pourquoi vous voulez/besoin de l'observateur, et donc la création d'un modèle dépend de son observateur n'est pas un drame terrible.

J'ai aussi une (relativement à la terre, je crois), le dégoût pour toute sorte d'observateur dépend de l'action d'un contrôleur. Soudain, vous avez à injecter de l'observer dans toute action de contrôleur (ou autre modèle) qui peut mettre à jour le modèle que vous désirez observer. Si vous pouvez garantir que votre application ne jamais modifier des instances par créer/mettre à jour les actions de contrôleur, vous aurez plus de puissance, mais ce n'est pas une hypothèse que je voudrais formuler une application rails (tenir compte des formulaires imbriqués, le modèle d'affaires de la logique de la mise à jour des associations, etc.)

Answer 5

WISPER est une excellente solution. Ma préférence personnelle pour les rappels est qu’ils sont déclenchés par les modèles, mais les événements sont seulement écoutés lorsqu’une demande arrive c'est-à-dire je ne veux pas les rappels ont tiré alors que je vais mettre en place des modèles dans les tests etc. mais je ne veux pas leur déclenché chaque fois que les contrôleurs sont impliqués. C’est vraiment facile à installer avec Wisper parce que vous pouvez lui dire de n’écouter que des événements à l’intérieur d’un bloc.