在 Rails 中，对象是否应该仅限于那些将具有视图和控制器的对象？答案

【问题标题】：In Rails should objects be limited to those that will have a view and controller?在 Rails 中，对象是否应该仅限于那些将具有视图和控制器的对象？
【发布时间】：2011-03-24 08:03:16
【问题描述】：

我一直在努力解决一个设计问题，我承认我对 OOP 和 RoR 都是新手，所以我确信这将是非常基础的。我有一个应用程序，我正在读取各种格式的文本文件，以解析与扑克牌相关的信息。所以我拥有的是三个实体：

一个文件对象。它存储文件的名称和路径以及一些其他属性，并具有与从文件读取相关的功能。这是 MVC，因为我可以添加一个文件并让它自动更新，或者我可以动态解析文件中的信息。
扑克手对象。这本质上只是存储有关谁玩了扑克牌以及操作和结果的信息。
解析器。这会根据正在读取的文件类型读取具有不同正则表达式模式的外部 JSON 文件。它还在 JSON 文件中包含一些基本的状态机信息，以便从解析器中删除大量逻辑。

所以我对解析器的最初感觉是它应该是它自己的对象。但后来我意识到它没有 V 或 C，因此可能不适合 Rails 的做事方式。它也没有文件对象以外的任何对象所需的任何功能，因此似乎适合文件。但与此同时，它与文件对象如此明显不同，以至于它似乎不适合。我想到了一个模块，但模块的意义似乎是多个对象共享某些功能的需求，而在这种情况下只有文件。

那么它应该是它自己的对象，在文件对象中，还是有其他我没有看到的替代方案？

【问题讨论】：

它不属于文件对象，但您可以将其作为类函数添加到文件对象的模型中。即如果 Document 是文件对象的模型，则可以在 Document 模型中定义self.parse_info(info)，这样就可以像Document.parse_info(json_string) 一样调用它。它将是一个类方法，而不是实例方法。
对不起，我可以理解让解析方法成为 File 类的一部分，并且它们将与 File 实例分开。但我不明白 Document 模型的来源。您是否假设 File 应该是从 Document 继承的？为什么解析对 Document 比对 File 更有意义，是否值得拥有一个 Document 类只是为了从 File 类中删除解析？我很感激这个建议，但我只是想理解..
我假设您将有一个名为 Document（或任何您想要的）的模型来表示您的文件，其中包含属性名称、文件路径等。Document 只是我给的一个名称到模型。

标签： ruby-on-rails ruby oop

【解决方案1】：

在 MVC 中关于某事物是否应为“M”的决定应基于它是否具有任何持久性（数据库驱动）数据。

模型不需要控制器或视图，控制器也不必与模型一对一地映射。但是，常见的“RESTful API”方法确实会产生强大的模型控制器对应关系。

在您的情况下，听起来它只是一段代码，它接受输入并返回一些其他已定义的模型，因此它可能最适合作为您的 lib/ 文件夹中的一个模块，您可以从其他一些中调用它模型或控制器

【讨论】：

我在某处读到，模块用于分离代码，当代码不“属于”其中任何一个对象时，这些代码将被多个对象使用。似乎一个函数只被一个对象使用，它应该以某种方式绑定到它。被多个对象使用并不是制作模块的必要条件吗？
Module 是一种进行多重继承的方式。这就像用其他语言实现一个接口，但已经为你完成了实现，所以你只需将其混入即可。
re：“关于某事物是否应该在 MVC 中为 'M' 的决定应基于它是否具有任何持久性（数据库驱动）数据。-正如对此的另一种看法：我认为将非 DB 相关的类作为模型是完全可以接受的。事实上，我来到这个问题的愿望是简单地回答“不！”它的标题，用巨大的红色 200 点字体。
Sammy，但我关于模块的问题再次出现在您的评论中。您提到这意味着跨对象的多重继承，那么这是否意味着它应该只在多个对象需要它的情况下使用？如果只有一个对象会调用模块中的函数，将其合并为类函数是否更有意义？
@Jeremy：模块有很多可能的用途，一个就是多重继承。如果只有一个类需要访问它，那么使用模块当然没有错。

【解决方案2】：

但后来我意识到它没有 V 或 C，因此可能不适合 Rails 的做事方式。

在我看来，它没有 V 或 C 的事实无关紧要。

如果您觉得解析器属于文件，则将其粘贴在那里。但是如果你不这样做（对我来说听起来不像），把它放在它自己的类中是完全可以的。不需要所有模型都有关联的控制器和视图，也不需要它们从 ActiveRecord::Base 或任何其他 ORM 派生，也不需要与数据库有任何关系。

关于它是属于 lib 还是 app/models - 我是这样看的：

如果它是您应用的一部分，则它属于 app/models。如果它不是您应用程序的一部分，例如外部库，请不要将其放在 app/models 中 - 将其放在 lib 文件夹中。

【讨论】：

【解决方案3】：

听起来您的解析器应该是一个实用程序类，而不是模型本身的一部分。这样想：模型应该包含您的应用程序完成其工作所需的所有逻辑。解析器的工作是将外部数据转换为该逻辑可以处理的格式；它不是逻辑本身的一部分。

我会将您的解析器放在 File 之外，并将其放在 lib/ 中。

【讨论】：

【解决方案4】：

我用来让实现领域相关逻辑的类在模型文件夹中。您应该知道，如果让它们进入 /lib 文件夹，它们将不会自动重新加载。

【讨论】：