用於UI模型和數據模型的Rails 3項目結構

這可能是一個非常愚蠢的問題，但我並沒有清楚地意識到如何最好地管理它，所以想把它放在這裏看看是什麼是常見的做法。用於UI模型和數據模型的Rails 3項目結構

從.NET我的web應用程序即將從不1個項目，這就是一切，我傾向於至少有一個數據層項目與堅持實體到數據庫並進行交易，這些模型代表說，在友好的一個DB 實體方式。然後我有我的UI項目，它有自己的模型，這是UI實體的表示，它可能具有基於驗證的信息，並且很可能是更多的減少模型，只暴露需要的內容。

所以我試圖走出這裏主要的一點是，雖然我們可以有一個用戶實體模型來表示可能會在用戶界面層和數據層略有不同...

現在快進到rails，你創建你的項目，它帶有數據庫連接（我相信它可以換成你想要的任何味道），驗證和其他框架和功能的整體方式。這似乎意味着我不再需要2個項目，只有1個包含在這裏和所有爲我完成的項目中，所以我需要擔心的是製作我的模型。

這是我有點困惑的部分，因爲可以說我正在使用ActiveRecord我需要製作我的模型並從ActiveRecord :: Base繼承，然後我需要設置此模型如何連接到其他模型所以我有我的模型的數據關注排序，現在我需要設置我的用戶界面的關注，關於驗證和字符串長度等...現在，這些去...我假設在同一模型，但然後模型不是隻是一個簡單的數據表示，它的一個東西包含數據庫和視圖的關注，誰知道還有什麼。

把所有東西放在這個地方似乎有點奇怪。我知道.net中有很多例子，其中數據模型中的大對象圖表示與數據模型非常不同，因此將它們耦合到一個模型中是明智的，或者Ruby和它的框架非常靈活在這個領域你沒有這些相同的問題？如果是的話是有一些例子或物品可以在我的心中，你是如何避開那些讓你分開您的問題有維護的代碼正常的問題凝固......

===編輯===

只是試圖澄清任何混淆，在我的文章中，當我說我的觀點模型和觀點關注時，我並不是指表達方面的擔憂。如果遇到這種情況，我很抱歉。我的意思是我可能（在一個普通的.net示例中）有一個UserStorage模型，它關心的是持久化User實體。然後，我在UI層有一個顯示許多用戶的視圖，一個顯示單個用戶的更詳細的視圖。您可能在這裏有兩個不同的模型，一個是UserSummary模型和一個UserDetails模型，兩者都部分代表一個用戶實體，但是針對有問題的實際視圖進行了自定義，因爲您可能會遇到UserDetails也變爲用戶組合和公司實體，這意味着有2個基於存儲的類被送入1個基於視圖的類。

在這些示例和指南中，您應該有1個視圖模型來處理這些問題以及存儲問題，在這種情況下，看起來好像我處於有視圖的情況模型是一個用戶和公司的組成，這個視圖層類擔心它的存儲，因爲它從來沒有存儲爲它自己，它在數據庫/數據存儲中存儲爲2個獨立的模型。

這是我試圖讓在這裏真正的問題，好像你的觀點被緊緊地捆綁在一起，而我已經習慣是2件不同的事情，不應該混......就像把你的主要存儲擔憂場和在同一板上布丁...

來源

2011-12-01 Grofit

在香草Rails中，沒有「視圖模型」這樣的東西。

該模型處理所有業務邏輯，包括query and persistence,association和validation。您似乎將驗證視爲關注的觀點，但這實際上是模型完整性的一個核心問題：它確實屬於此類。

這並不是說，驗證不應該在視圖（客戶端）發生過，但該機型擁有自己的核心業務規則，並且是驗證規則最終檢查的地方。

你會希望你的模型保存你的應用程序的大部分邏輯。這意味着諸如檢查用戶是有效的還是主動的，查找相關記錄等等。幾乎所有不是表象的都屬於模型。

在視圖中，Rails提供了用於格式化的輔助方法。這些來自包含在視圖實例中的模塊。 Helper方法可以訪問視圖（您的模型）的實例變量並用於呈現它們。

在某些情況下，將裸眼模型傳遞到視圖中會使事物難以保持模塊化和有組織性。有些人更喜歡使用Presenters在將模型傳遞給視圖之前對其進行封裝。它可以幫助組織你的代碼，但它也是一個額外的層。演示者在Rails中並不是標準配置，但如果對您的應用程序有意義，則可以添加此模式using plain ruby objects或類似draper的庫。

編輯：哦，看，a most excellent blog post就這個話題出現在今天，來自最優秀的Thoughtbot。

來源

2011-12-02 10:22:24

你100％正確，數據完整性是一個存儲問題，如果你可以免費獲得視圖級驗證，那麼一切都會更好。這就是我所追求的，因爲我習慣於我的視圖模型只是沒有邏輯的POCO/POJO，並且如果Rails傾向於將其模型視爲更多上下文數據的入口，那麼這對於爲什麼事情是這樣完成的。模型本身具有邏輯似乎仍然很危險，但這很可能是因爲我對Ruby/Rails沒有經驗...... Rails MVC中的模型更像是MVVM中的ModelView – Grofit

查看了演示者模式鏈接，並解釋了這一點我想到的那種東西，所以會給你鏈接的答案，並給我一個關於Rails如何看待其模型，視圖和控制器之間關係的清晰思路。 – Grofit

簡而言之：

如果它的有關數據（存儲，完整性等）它會在模型
如果它是關於處理/計算數據（例如查找所有待處理訂單）它會在型號
如果它是關於呈現數據（掛單應該有一個紅色的取消按鈕），它會在視圖

既然你似乎是一個有經驗的開發人員，你可能會從本書http://www.manning.com/katz/其對面向受益對Rails不熟悉的開發人員（但不適用於Web編程）。

另外，還有一個免費的在線教程還http://ruby.railstutorial.org/

當然，Rails的導遊總是一個很好的信息來源：http://guides.rubyonrails.org/

來源

2011-12-01 16:52:48

感謝您的信息，前2點是似乎立即響起警鐘的那一點。由於這些是我在這個問題上關注的兩個問題。對於我在一個模型中同時擔憂這一點似乎很奇怪。雖然也許我在最初的問題中沒有正確解釋，但當我說View的關注點時，我並不是在談論實際的表達方面的問題，我只是在談論當你需要改變模型以適應有問題的視圖時，更新我的主要問題來反映這一點。也會去閱讀Katz的文章，這些指南是讓我擔心的...... – Grofit

-1

沒有一個在你的問題MVC中提到，你應該看看進入模型視圖控制器模式。

您還應該瞭解遷移如何工作。

來源

2011-12-01 16:53:25

那是因爲如果你使用MVVM，MVP（非常類似於我所知道的MVC）。無論你用什麼模式來抽象你的UI，問題依然存在（如果你擔心分離問題）。我沒有看到MVC或任何其他UI抽象模式如何回答這個問題，因爲這隻涉及UI模型（Mvc的模型部分），您將數據導入該模型的方式就是這裏討論的內容。 – Grofit

在.net中使用MVVM的原因是因爲後面的代碼與佈局文件緊密耦合，因此您必須進一步抽象代碼以操縱模型中的數據。與MVC控制器就像一個共享的代碼背後的意見。如果您使用JavaScript庫（如backbonejs或knockoutjs）通過ajax執行UI中的所有操作，則MVVM更爲常見。你將不得不使用類似acts_as_api的方式將api附加到你的應用程序 –

我認爲你錯過了這一點。這裏的問題是，你在1個模型中有存儲問題和用戶需求問題（或者Rails指南和文章指出）。你只是在談論硬幣的一面。在MVC中，您的控制器通常會處理從您擁有的任何數據庫/抽象中獲取數據並將其提供給視圖模型以傳遞給您的視圖。在MVVM中，視圖模型通常是獲取數據並將其直接綁定到用戶界面的視圖模型，無論哪種方式，您都有一個封裝視圖使用的數據的模型，通常存儲問題在其他地方。 – Grofit

用於UI模型和數據模型的Rails 3項目結構

回答

相關問題