Spring MVC和Web应用程序架构

Question

我对Spring MVC的理解是，View层负责填充数据的用户界面，Model表示可用于View Layer的值的Map，Controller控制如何以及传递给哪些数据模型以及执行的业务逻辑。 ＆＃34;业务逻辑＆＃34;可以划分为一个或多个其他层 - 通常是服务层和/或数据访问层。这是对的吗？

我已经看到了MVC模式的其他解释，其中模型被视为具有实体，数据访问对象和服务的层。 View负责用户界面。 Controller是两者之间的门户。我不认为这适用于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），XML绑定框架（如JAXB和Castor），JSON绑定框架，如Jackson和GSON等。 Spring MVC API很容易与视图生成技术集成，因此框架可以相对容易地适应新技术。

由于Spring MVC是一个表示层框架，因此它没有指定，推荐或强制执行业务逻辑的方式。但是，通常最好将业务逻辑保留在表示层之外（有关详细信息，请参阅SOLID principle）。例如，如果您希望为某些用户或业务合作伙伴提供对业务逻辑的编程访问，那么最好将业务逻辑放在Web表示层将调用的独立层中。然后，您可以创建一个薄层，该层也可以调用相同的业务逻辑层，并允许使用SOAP，REST，EDI等数据交换机制以编程方式访问外部用户。

Answer 2

MVC 是UI层。

模型是对象的地图，表示视图的数据。这些对象通常是JPA实体，但不一定是。它可以是一个表示登录表单中的用户名和密码的简单类。

在模型类中保留一些逻辑。例如，如果要计算贷款的利率，可以在模型类中执行此操作。对于复杂的逻辑，特别是涉及多个模型类时，请使用服务。

模型类必须完全独立于视图和控制器，因为它们可以在没有它们的情况下存在。

控制器响应HTTP请求。通常，它负责加载正确的模型并选择正确的视图，并返回此信息。控制器应该非常愚蠢。

你想要“胖模特和瘦小的控制器”。尽可能多地保留模型中的逻辑。

视图是可以使用模型的JSP或模板（如Thymeleaf或Freemarker）。诀窍是在视图中尽可能少地使用逻辑。