Je fais un petit module d'envoi de message. Il gérera les messages en file d'attente d'une demande à ramasser par un ouvrier d'arrière-plan pour envoyer un courrier électronique / SMS (ou loger de manière appropriée pour les tests).
Question: Est-ce un modèle (sous / app / modèles) ou une lib (sous / lib).
Je voudrais une religion à ce sujet.
Théorie A: (Ma théorie actuelle) Sauf si vous êtes sous-classement ActionMailer :: Base ou ActiveRecord :: Base, etc., votre code devrait entrer dans la lib.
Théorie B: (Théorie Je me penche vers) Les choses spécifiques à l'application devraient être dans le modèle. Tout ce qui pourrait être d'une utilisation générale devrait être dans la lib.
THÉORY C: Seuls les "modèles de données" doivent être dans "Modèles". Les sous-classes ActionMailer brisent cette règle, cependant.
Aussi loin que je sache, de toute façon ça va bien fonctionner, mais je cherche des raisons subtiles fonctionnelles ou philosophiques d'un contre l'autre.
pensées?
3 Réponses :
Si des messages hériter ou non d'ActiveRecord ou d'ActionMailer, vous souhaitez probablement un modèle pour tous les objets que vos vues et vos contrôleurs interagissent. Dans votre cas, ils géreront des instances de la classe de messages - vous voulez un modèle pour cela.
Tant que le module d'envoi de messages - l'extraction d'une bibliothèque est excellent si vous envisagez de réutiliser le code ailleurs où vous pouvez simplement inclure le module de n'importe quelle classe.
Comme il s'agit simplement d'un "petit" module d'envoi de message, vous voudrez peut-être démarrer dans le modèle et éventuellement extraire à un module séparé s'il pourrait être utile ailleurs ou que votre modèle devient trop salissant.
Pensez-vous que cette carte de la théorie b ci-dessus?
Oui, votre théorie B est correcte. Cependant, dans la plupart des cas, vous voulez toujours un modèle pour quelque chose qui pourrait ne pas être spécifique à l'application. Prendre par exemple une classe de messages. Oui, vous pouvez interagir avec des messages dans plusieurs applications différentes de la même manière, mais il y aura presque toujours des occasions où vous voudrez remplacer ou personnaliser le comportement du message sur une base par application. Donc, créez le modèle dans toutes les applications et devez-le inclure les Lib (s).
Vous devriez probablement penser plus en termes d'activité sous-jacente ici. Les modèles, comme leur nom l'indique, sont là pour représenter (modèle) un système ou un processus réel. Donc, la règle d'un pouce devrait être ceci: cette entité joue-t-elle un rôle dans le système que j'essaie d'exprimer dans ma demande? Si la réponse est positive, l'entité est un bon candidat à être un modèle. Cependant, il serait parfaitement correct pour implémenter la fonctionnalité principale de votre module de messagerie dans une bibliothèque séparée pour une réutilisation ultérieure et l'inclure simplement dans le modèle.
Pensez-vous que cette carte de la théorie b ci-dessus?
J'aime la théorie de la "modèle de données" et j'essaie de m'en tenir quand je peux, mais je pense que Bensie et Milan ont la bonne idée. Si vous avez des vues et des contrôleurs associés à cela, il devrait être avec des modèles. Si vous ne faites que référencer les fonctionnalités d'une autre classe, mettez-la dans la lib.
Je suis d'accord avec vous: si cela n'hérite pas d'ActiveRecord et de CO., Ce ne devrait pas être un modèle. Je n'ai pas eu l'accusé de dire que l'opinion dans une réponse complète pensée ^^