Question

使用 Spring 控制器类（使用@ ModelAttribute ）和 jsp 同时准备模型或该模型必须仅由 Spring 和 jsp 中的视图准备？这个想法来自这个topic。我有一个Controller类：

@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中）是否给了我更多的权力，例如覆盖模型或完全没必要？当两者都存在时，第二个声明是否会覆盖第一个声明？

Answer 1

我认为你应该在弹簧控制器中完全准备你的模型。然后视图应尽可能被动，即。仅显示从控制器接收的模型属性，而对应用程序逻辑没有进一步了解。这种方法可以让您清晰地分离关注点，并且您可以尽可能独立地查看视图，并且可以轻松切换到不同的视图技术 - 例如。百里香叶或自由标记模板。 MVC的整个想法是分离表示层，并通过泄漏业务逻辑来查看您创建不必要的依赖项。

您的视图应该尽可能简单，因为泄漏到视图的逻辑使得测试和重用变得非常困难。另一方面，如果您的逻辑很好地分离，您可以轻松地测试它并轻松地重复使用它。理想情况下，业务逻辑应该完全独立于Web环境。

Answer 2

这个实现有很多问题。

是MVC吗？

如果JSP知道Model，为什么我们需要控制器。让我们删除路由引擎并直接使用JSP来使用Model。但随后应用程序将是单片的。我相信你不希望这样。我们有两种主要的MVC风格。在两者中，控制器是面向前方的对象。它接收命令，解释它，使用数据层并获取模型。如果需要，将模型转换为viewModel，然后将此对象传递给视图。

为什么选择viewModel？

假设我们正在屏幕上实现分页。我们正在显示人员名单。人是你的模特，但你的视图也需要知道页码，页面大小等。因此你的模型可能不适合这种情况。

假设我们需要来自多个表的数据才能显示在屏幕上。这些数据在某种程度上是相关的。现在您将传递单独的模型对象来查看并让它执行所有业务逻辑吗？理想情况下没有。

设计不应该支持DTO或ViewModel或命令和查询吗？

我们希望我们的应用程序设计得当。如上所述，我们需要在处理后将数据发送到视图或客户端（REST）。除非我们只是创建CRUD内容，否则处理过的数据可能无法映射到您的域。如果您想实施CQS或CQRS怎么办？

分离在哪里，SOLID在哪里？

如果我的观点是执行业务逻辑，那么'S'在哪里？如果视图知道模型并且需要在模型中稍有变化就更改那么“O”在哪里？如果我想从命令（CQS）中分离查询并分别缩放这两件事怎么办？

总结我会说，是的，你可以做到这一点但是如果你正在开发一个体面的应用程序或者你认为它最终会成为一个应用程序并不好。我见过人们使用从ORM开始的模型实体到控制器来查看。它会工作，但问题是你想要一个单片和紧密耦合的应用程序。根据我的经验，表示逻辑（视图）具有非常不同的逻辑和数据需求，与控制器相比，数据访问层也是如此。

Answer 3

通过定义在视图和类com.example.ApplicationCreateForm之间创建紧密耦合，使用spring mvc，您可以在控制器，视图和模型之间实现松散耦合，可能会发生更改模型名称但仍具有相同属性的情况在它可能足够的视图中，在上面的例子中，你需要更新你的视图，但如果你使用的是Spring MVC则不需要。

Answer 4

由于Spring带有松散耦合的概念，使您的代码更易于测试，因此您应始终牢记关注点分离是您的首要任务。因此，最好在Controller中完全准备模型，而不是在视图中。

保持简单，让控制器负责准备模型，并保持视图仅显示模型。

所以，你的问题很大NO。第二个宣言不会让你变得强大，而是帮助你被束缚。

在控制器和jsp中将模型与视图分开的Spring最佳实践？

4 个答案: