我对Spring MVC的理解是，View层负责填充数据的用户界面，Model表示可用于View Layer的值的Map，Controller控制如何以及将哪些数据传递给Model . 以及执行什么业务逻辑 . “业务逻辑”可以分为一个或多个其他层 - 通常是服务层和/或数据访问层 . 它是否正确？
我已经看到了MVC模式的其他解释，其中模型被视为具有实体，数据访问对象和服务的层 . View负责用户界面 . Controller是两者之间的门户 . 我认为这不适用于Spring MVC和其他用于Web框架的MVC实现 .
2 回答
您在第一段中概述的理解大多是正确的 . 我略有不同的地方在于查看
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） . 诀窍是在视图中尽可能少地使用逻辑 .