最好同时使用Spring Controller类（带有@ ModelAttribute）和jsp来准备模型，还是仅由Spring和来自jsp的视图来准备模型？这个想法来自这个话题。我有一个控制器类：
@RequestMapping(value = {"", "/"}, method = RequestMethod.GET, params = "mode=create")
public ModelAndView showCreatePage(@ModelAttribute("createForm") ApplicationCreateForm form)
{
return customMethod("some string");
}
在我的jsp中，我有：
<jsp:useBean id="createForm" scope="request" class="com.example.ApplicationCreateForm"/>
我不需要使用要向用户提供的信息来填充表单，所有字段均为空。
因此，据我了解，我已经两次声明了ApplicationCreateForm bean，具有相同的作用域-请求。
同时使用两者是一种好的设计习惯吗？有什么理由吗？第二个声明（在jsp中）是否赋予我更多权力，例如覆盖模型或完全没有必要？当两个声明都存在时，第二个声明是否会覆盖第一个？
此实现有很多问题。
是MVC吗？
如果JSP了解Model，我们为什么需要控制器。让我们删除路由引擎并直接使用JSP来使用Model。但是，此应用程序将是整体的。我相信你不想要那样。我们有两种主要的MVC。在这两种情况下，控制器都是正面对象。它接收命令，解释命令，使用数据层并获取模型。如果需要，将模型转换为viewModel，然后将该对象传递给视图。
为什么要viewModel？
假设我们正在屏幕上实现分页。我们正在显示人员清单。人员是您的模型，但是您的视图也需要知道页码，页面大小等。因此，在这种情况下，您的模型可能不适合。
假设我们需要多个表中的数据才能显示在屏幕上。该数据以某种方式相关。现在，您将传递单独的模型对象来查看并让其执行所有业务逻辑吗？理想情况下不。
设计不应该支持DTO或ViewModel或命令和查询吗？
我们希望我们的应用程序经过适当设计。如上所述，我们需要在处理后发送数据以查看或客户端（REST）。除非我们只是创建CRUD内容，否则处理后的数据可能不会映射到您的域。如果要实现CQS或CQRS，该怎么办？
分离在哪里，SOLID在哪里？
如果我的观点是执行业务逻辑，那么“ S”在哪里？如果视图了解模型并且需要在模型的任何更改中进行更改，那么“ O”在哪里？如果我想将查询与命令（CQS）分开并分别缩放这两件事怎么办？
总而言之，我会说，是的，您可以这样做，但是如果您正在开发一个体面的应用程序，或者您认为它将最终成为一个应用程序，那就不好了。我见过人们使用从ORM开始到控制器进行查看的模型实体。它将起作用，但问题是您是否需要一个整体且紧密耦合的应用程序。根据我的经验，与控制器相比，表示逻辑（视图）具有非常不同的逻辑和数据需求，数据访问层也是如此。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句