MVC架構模式

Question

我一直在做Java和Ruby（以及使用框架）一段時間，我知道MVC是一種分離代碼的方法。事情是，我想我從來沒有真正以它應該的方式使用它。

第一個問題是：業務邏輯，這是什麼意思？業務邏輯是否意味着該應用程序特有的邏輯？假設你正在建造一個衛星系統。業務邏輯是該衛星系統獨特的代碼，並使其工作？

「域」是什麼意思？就像域邏輯或域中的術語一樣。 「保持你的模型聰明，控制器很薄並且看起來很愚蠢」。這句話清楚地表明，我加載了太多代碼的控制器是寫它的錯誤方式。

作爲一個例子。如果你有一個BankAccount類。那麼這個類應該提供一些行爲方法，比如驗證等，以及getter/setter？

控制器應該做什麼？只需將視圖中的輸入/事件重定向到模型，並可能更新視圖（webframeworks就是這種情況）。

例如在Java和JPA中，您有用於查找實體的entityManager，可能對它們做了某些操作等。如果在控制器中使用此entitymanager，或者應該製作另一個名爲例如控制器使用的「服務」。但是，這個服務器層是否屬於MVC中的Model？你如何在Rails中做到這一點？

我不明白我的模型和控制器的概念。

Answer 1

將應用程序視爲分層。在每個圖層上工作時，總要自己思考一下，「這個圖層是依賴於它上面的圖層還是可以獨立工作？」這是一個好的MVC應用程序的基礎。

當想到MVC風格的應用程序中的圖層時，有幾個。

在我看來，層（從上到下）是視圖，控制器，業務邏輯和數據訪問。

該視圖可能是JSP或甚至來自jQuery的AJAX請求。這是用戶與您的應用程序交互的地方。該視圖將信息發送到業務邏輯層以進行工作。

應該編寫控制器來收集從視圖發送給它的數據，以業務邏輯可以理解的方式轉換它，然後將信息傳遞到業務邏輯層。控制器也可以從業務邏輯層獲取信息，對其進行轉換，並將其發送回視圖。在這裏不應該發生真正的「商業邏輯」。將其視爲視圖和業務對象層之間的代理。這也是驗證視圖提交的數據的好地方。

業務邏輯是一個您可以在中間找到的層，通常位於控制器和數據訪問層之間。這也可以稱爲服務層。它應該被寫成不知道什麼是調用它。如果寫入正確，則可以在獨立應用程序中使用此圖層。這裏是很多應用程序智能應該發生的地方。很多時候，這個層只是在這裏調用數據訪問層並將結果返回給控制器。但是，還有很多其他的東西可以用在數據處理，計算，數據安全性，驗證等方面。

數據訪問層的編寫方式應該是輸入，檢索合適的數據，將其轉換爲可用的形式並返回。這個層不應該知道或關心叫什麼，應該這樣寫。再一次，這個層不應該知道它在Web應用程序或獨立應用程序中。這裏有很多選項可以讓你的表單或ORM（對象關係映射）框架的生活變得更簡單。如果你的應用程序是一個微不足道的步驟，你應該考慮使用一個。

在傳統意義上，模型可能是業務邏輯層和數據訪問層，以及與之相關的域對象。

使用「的BankAccount」爲例：

「的BankAccount」聽起來更像一個域對象（在數據庫中的數據的表示法）高於具有邏輯在它的類。通常，域對象只有他們需要的字段（賬號，餘額等）與getter和setter。

用戶可能會登錄到他們的銀行網站。在登錄時，視圖將用戶名發送給控制器（BankAccountController）。控制器將這些信息從請求中取出併發送到服務層（BankAccountService）。服務層會將這些信息發送給數據訪問層，該層對用戶可能擁有的BankAccounts進行查詢，並將其返回給服務層，並將其返回給控制器。控制器將以某種方式操作這些信息，以使視圖層可以將它們顯示給用戶。例如，當用戶在賬戶之間轉賬時，會有類似的一系列事件。

希望這可以幫助...讓我知道如果你有任何問題或者如果有什麼不明確的。

編輯：

除了通過發佈其他用戶的聯繫，維基百科有一個簡短的，但對MVC相當不錯的文章。

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller