Rails：当模型？当一个lib？

我正在发一个短信发送模块。它会处理来自请求的排队消息，以供后台工作人员发送电子邮件/短信（或适当地登录以进行测试）。Rails：当模型？当一个lib？

问题：这是模型（在/ app/models下）还是lib（在/ lib下）。

我想在这个宗教。

理论：（我目前的理论），除非你继承的ActionMailer :: Base或ActiveRecord的::基地等，你的代码应该进入库。理论B :(理论我倾向于）应用特定的东西应该在模型中。任何可能普遍使用的东西都应该在lib中。

理论C：只有“数据模型”应该在'模型'中。尽管如此，ActionMailer子类破坏了这个规则。

据我所知，无论哪种方式，它会正常工作，但我正在寻找一个与其他任何细微的功能或哲学原因。

想法？

来源

2009-11-02 Kevin Moore

我同意你的看法：如果它不是从ActiveRecord和co。继承的，它不应该是一个模型。我没有足够的权利说出将这个观点转化为一个完整的答案思考^^ – marcgg 2009-11-02 00:28:42

是否将邮件从ActiveRecord的或继承的ActionMailer，你可能想为您的视图和控制器与交互的任何对象的模型。在你的情况下，他们将处理Message类的实例 - 你需要一个模型。

对于消息发送模块 - 提取出库是伟大的，如果你打算在其他地方重用代码，在那里你可以包括任何一类的模块。

由于这只是一个“小”的消息发送模块，您可能需要在模型开始，最终提取出一个单独的模块，它是否可以在其他地方有用或模型过于杂乱。

来源

2009-11-02 01:08:37 bensie

您是否认为上面的理论B的这张地图？ – 2009-11-02 20:36:24

是的，你的理论B是正确的。但是，在大多数情况下，您仍然需要一个模型来解决某些可能不适用于特定应用的问题以一个消息类为例。是的，您可以用同样的方式与几个不同应用程序中的消息进行交互，但几乎总是会出现需要根据每个应用程序重写或自定义消息行为的情况。因此，在所有应用程序中创建模型，并使其包含lib（s）。 – bensie 2009-11-03 20:55:41

您应该在这里考虑更多的底层业务。正如其名字所暗示的，模型在这里代表（模型化）一些现实世界的系统或过程。所以，拇指的规则应该是这样的：这个实体在我试图在我的应用程序中表达的系统中扮演什么角色？如果答案是肯定的，那么该实体是成为模特的好候选人。但是，在某个单独的库中实现消息传递模块的核心功能以便以后重用并将其包含在模型中将是完全可以的。

来源

2009-11-02 01:15:27

你认为这张地图上面的理论B？ – 2009-11-02 21:20:20

我喜欢的“数据模型”理论，我要尽量坚持下去时，我可以，但我认为Bensie和米兰有正确的想法。如果您有与之关联的视图和控制器，则应该使用模型。如果您仅从另一个类中引用该功能，请将其放入lib中。

来源

2009-11-03 19:29:53 cgr

Rails：当模型？当一个lib？

回答

相关问题