Spring MVC和Web應用程序體系結構

Question

我對Spring MVC的理解是，View層負責填充數據的用戶界面，Model代表View層可用的值的Map，Controller控制以及將什麼數據傳遞給模型以及執行什麼業務邏輯。 「業務邏輯」可以分爲一個或多個其他層 - 通常是服務層和/或數據訪問層。它是否正確？

我已經看到MVC模式的其他解釋，其中模型被認爲是實體，數據訪問對象和服務的一個層。該視圖負責用戶界面。控制器是兩者之間的門戶。我不認爲這適用於Spring MVC和其他用於web框架的MVC實現。

Answer 1

您的理解大致正確。如果我略有不同，請將Model,View和Controller作爲應用程序的單獨圖層（因爲您有對View layer的引用）。 MVC是實現用戶界面的模式，通常應用程序中的用戶界面是Presentation layer的一部分。除了MVC之外，還有其他用於實現表示層的模式，例如MVVM,MVP，PAC等。

Spring MVC建立在Spring框架之上。如果您熟悉Spring框架，您會知道它是Java的許多可用Dependency Injection框架之一。 Spring MVC控制器是普通的Spring管理的bean，可以被Spring DI容器發現，並且可以注入其他Spring bean。

在Spring MVC應用程序模型的對象可以是任何Java類的實例，無論是在內置數據類型，如String，Long，BigInteger等，或用戶定義的類和枚舉。

視圖可以再次成爲最終用戶的任何有意義的東西 - HTML頁面，XML文檔，JSON文檔，PDF文檔，Excel電子表格等等。 Spring MVC不提供任何視圖生成機制。不過，它提供了對幾種現有視圖生成技術的集成，如常規JSP，JSTL，Freemarker，Java，Thymeleaf和StringTemplate等模板引擎，Jasper Reports等報告框架，JAXB和Castor等XML綁定框架，JSON如傑克遜和GSON等有約束力的框架，等等。 Spring MVC API相當容易與視圖生成技術集成，因此該框架可以相對容易地適應新技術。

由於Spring MVC是一個表示層框架，它沒有指定，推薦或強制執行業務邏輯。但是，將業務邏輯放在表示層之外通常是一個好主意（有關詳細信息，請參見SOLID principle）。例如，如果您希望爲某些用戶或業務合作伙伴提供對您的業務邏輯的編程訪問權限，則最好將業務邏輯放在Web表示層將調用的獨立層中。然後可以創建一個薄層還調用相同的業務邏輯層和允許使用數據交換機制的外部用戶，例如SOAP，REST，EDI等的編程訪問

Answer 2

MVC 是 UI層。

模型是對象的映射圖，表示您的視圖的數據。這些對象通常是JPA實體，但不一定是。它可以是一個簡單的類，代表登錄表單中的用戶名和密碼。

在模型類中保留一些邏輯。例如，如果你想計算貸款的利率，你可以在模型類中做到這一點。對於複雜的邏輯，特別是涉及多個模型類時，請使用服務。

模型類必須完全獨立於視圖和控制器，因爲它們可以沒有它們而存在。

控制器響應HTTP請求。通常它負責加載正確的模型並選擇正確的視圖，並返回此信息。控制器應該很笨。

你想要「胖模特和瘦身控制器」。儘可能多地保留模型中的邏輯。

視圖是可以使用模型的JSP或模板（如Thymeleaf或Freemarker）。訣竅是在視圖中儘可能少的邏輯。