在Rails中應該將對象限制爲那些將具有視圖和控制器的對象？

Question

我一直在努力解決設計問題，我承認我對OOP和RoR都是新手，所以我相信這將是非常基礎的。我有一個應用程序，我正在閱讀各種格式的文本文件，以解析與撲克牌手有關的信息。所以我有三個實體：

• 一個文件對象。這存儲文件的名稱和路徑以及其他一些屬性，並具有與從文件讀取相關的功能。這是MVC，因爲我可以添加一個文件並將其自動更新，或者我可以即時解析文件中的信息。

• 撲克手對象。這實質上只存儲了誰玩牌的信息以及行動和結果。

• 解析器。這會根據正在讀取的文件的類型讀取具有不同正則表達式模式的外部JSON文件。它還在JSON文件中具有一些基本的狀態機信息，以便從解析器中刪除大量的邏輯。

所以我最初對解析器的感覺是它應該是它自己的對象。但後來我意識到它沒有V或C，所以可能不適合Rails的做事方式。它也沒有任何除文件對象之外的任何對象所需的功能，因此似乎適合於該文件。但與此同時，它與文件對象完全不同，它似乎不適合。我想到了一個模塊，但模塊的重點似乎是，如果多個對象共享一些功能的需要，在這種情況下，只有文件。

因此，它應該是它自己的對象，在文件對象內，還是有一些其他的選擇，我沒有看到？

Answer 1

有關MVC中的某些內容是否應爲「M」的決定應基於它是否具有任何持久性（數據庫驅動的）數據。

模型不需要控制器或視圖，並且控制器不必與模型一對一映射。但是，通用的「RESTful API」方法確實會產生強大的模型< =>控制器對應關係。

在你的情況下，它聽起來像是一塊代碼，它需要輸入並返回一些其他已定義的模型，所以它可能最好作爲lib/文件夾中的一個模塊，可以從其他模型調用或控制器

Answer 2

我用它來讓模型文件夾中實現與域相關的邏輯的類。您應該意識到，如果放入/ lib文件夾，它們將不會自動重新加載。

Answer 3

但後來我意識到它沒有V或C，所以可能不適合Rails的做事方式。

事實上，它沒有V或C在我看來是無關緊要的。

如果您覺得解析器屬於File，那麼將它粘貼在那裏。但是如果你不這樣做（對我來說聽起來不像），將它固定在自己的課堂上是完全可以的。不需要所有的模型都有關聯的控制器和視圖，也不需要它們從ActiveRecord :: Base或任何其他ORM派生，也不需要與數據庫有任何關係。

關於它是否屬於在lib或應用/型號 - 我看它是這樣的：

如果這是你的應用程序的一部分，它屬於在app /模型。如果它不是應用程序的一部分，就像外部庫一樣，請不要將其放入應用程序/模型中 - 將其放入lib文件夾中。

Answer 4

聽起來你的解析器應該是一個工具類，而不是模型本身的一部分。這樣考慮：模型應該包含您的應用程序需要完成其工作的所有邏輯。解析器的工作是將外部數據轉換爲邏輯可以工作的格式;它不是邏輯本身的一部分。

我會讓你的解析器在File之外，並把它放在lib /中。