ruby​​ on rails dto objects - 你在哪裏存儲它們？

Question

這裏有人使用DTO's將數據從控制器傳輸到視圖嗎？如果是這樣，你會在哪裏推薦存儲這些文件？/apps/dtos，然後讓他們鏡像視圖dir結構？有關使用rspec測試這些動物的任何建議？

Answer 1

Rails約定不是爲控制器層和視圖層使用分佈式層。分離就在那裏，但與Java領域中看到的框架類型相比，它是合乎邏輯的，相對較薄/輕量級的。

基本架構是控制器設置在相應視圖中可用的實例變量。在一般情況下，實例變量將是模型實例或模型實例（來自數據庫）的集合。模型應該是您業務邏輯的核心。控制器協調數據流。視圖顯示它。 Helpers用於在視圖中設置顯示值的格式......任何需要模型值並僅僅爲了顯示目的而執行某些操作的東西（您可能會發現重複使用的輔助方法實際上可能更適合模型本身）。但是，如果您發現某個視圖需要許多不同模型的知識，則可能會發現將模型封裝到另一個更高級別的對象中更容易。沒有什麼能阻止你創建收集和協調實際AR模型的非活動記錄對象。然後，您可以在控制器中實例化這些對象，並讓它們可用於視圖。你通常必須在控制器中處於相當密集的複雜程度才能需要這種類型的東西。

我傾向於將這些對象放入應用程序/模型 - Rails已經加載了這個目錄中的所有東西，從配置/期望的角度來看可以讓事情變得簡單。

Answer 2

如果您來自.NET或J2EE背景，您可能會考慮類似DTO的模式。您可能會也可能不會感到驚訝（也可能很高興）得知Rails不按照慣例那樣做事。

尤其沒有必要在控制器和視圖之間正式傳輸（或存儲）序列化的對象。在控制器中創建的實例變量（通常是模型屬性值）在框架提供的視圖中可用，無需任何額外的編程工作。

Answer 3

我被告知的一般情況是，這是由'助手'處理的工作。他們基本上可以幫助你設置模型對象的格式，以便從視圖中消費視圖。所以它絕對不是概念的1-1映射，但這就是rails世界的想法

Answer 4

請不要聽其他的答案。他們很可怕。 Rails助手很糟糕。在任何地方使用rails模型都很糟糕。我求求你，正確設計你的應用，並決定你是否需要DTOs。決定是否真的想要rails模型來處理與數據庫通信以外的其他事情。決定你是否真的不想在你的應用和導軌之間有一層，等等。 Rails設計僅適用於需要快速開發的小應用程序或應用程序。但是，如果它不是微不足道的，並且您希望開發一段時間，請將您的時間投入到適當的設計中。不要害怕打破Rails的便利。並可能與你的力量。