我对 Spring MVC 的理解是，View 层负责填充数据的用户界面，Model 表示可供 View 层使用的值的 Map，而 Controller 控制传递数据的方式和内容模型以及执行什么业务逻辑。 “业务逻辑”可以分为一个或多个其他层——通常是服务层和/或数据访问层。这是正确的吗？
我已经看到了 MVC 模式的其他解释，其中模型被视为具有实体、数据访问对象和服务的层。视图负责用户界面。而Controller是两者之间的网关。我认为这不适用于 Spring MVC 和其他 Web 框架的 MVC 实现。
【问题讨论】：
您在第一段中概述的理解大部分是正确的。我略有不同的地方是将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 等数据交换机制对外部用户进行编程访问。
【讨论】：
MVC 是 UI 层。
模型是对象的映射，代表视图的数据。这些对象通常是 JPA 实体，但不一定是。它可以是一个简单的类，表示登录表单中的用户名和密码。
在模型类中保留一些逻辑。例如，如果您想计算贷款利率，您可以在模型类中执行此操作。对于复杂的逻辑，特别是当涉及多个模型类时，使用一个服务。
模型类必须完全独立于视图和控制器，因为它们可以在没有它们的情况下存在。
控制器响应 HTTP 请求。通常它负责加载正确的模型并选择正确的视图，并返回此信息。控制器应该很笨。
您想要“胖模型和瘦控制器”。在模型中保留尽可能多的逻辑。
视图是可以使用模型的 JSP 或模板（如 Thymeleaf 或 Freemarker）。诀窍是视图中的逻辑尽可能少。
【讨论】：