Question

假设我在GSP中对域进行了页面导入，例如：

<%@ page import="com.sample.entity.Book" %>

通过

将其用于您的网页

<g:select from="${Book.list()}"
          optionKey="id"
          optionValue="title"
          name="bookSample"/>

这种糟糕的编程习惯是否使用导入？我是Grails的新手并且已经在很多教程中看到过这种做法，但是我的领导会阻止我这样做，因为根据他的说法，黑客可以轻松地从数据库中获取数据。我一直反对它，但我想我需要一些支持。

我同意上述内容，使用控制器获取图书清单更为理想 - 但我认为我不认为使用＆lt;％@ page import =“”％＆gt;编码很糟糕，因为它会使页面容易受到攻击。

我知道GSP已经编译，因此HTML页面无法看到导入的参考。

更新：感谢大家提供的意见。我已经更新了这个问题，让它更加专注。如果有人告诉你这是错的，这就是原因 - 你有点超越最佳实践，更多地考虑安全性，我真的无法想象如何通过导入

Answer 1

我不太确定“黑客会做坏事”的推理，但是有一种更好的方法可以直接在GSP中使用GORM。

让我们明确一点，在GSP中直接使用GORM在技术上并没有错，这只是一个不好的做法。为什么？它并没有让你清楚地分离你的模型和视图。

您的观点（GSP）不应该构建模型。它应该只是用它来渲染一个视图。但是，您的控制器确实应该构建您的视图（GSP）使用的模型。

在您的示例中，该模型来自GORM查询。但是，将来您最终可能会将其委托给使用某些微服务的服务。

由于模型是在控制器而不是GSP中构建的，因此您无需梳理所有GSP并找到重构所需的位置。它应该像更换控制器一样简单。

这就是为什么你应该避免直接在GSP中使用GORM的真正原因。分离关注点。

就域名的实际导入而言？这并不是一个糟糕的做法，因为您的模型可能包含域实例。它有点冗长（大多数情况下并不是真的需要），但冗长也有助于记录视图正在使用的域类。

我通常不在我的GSP中使用特定的导入，因为我发现模型会随着时间的推移而发生变化并且维持导入成为一个问题。

更新在给予它更多的想法后，我不能为我的生活提出一个真正的理由，为什么在您的GSP中使用导入将被视为安全风险。你是领导有很多解释要做，或者你需要替换他。

Answer 2

我发现你在GSP中使用的逻辑越少越好，随着它们变得越大越复杂，它们变得难以管理并且难以调试;特别是如果你有嵌套模板。

Grails的脚手架本身就是这样做的，我认为这是一个糟糕的做法 - 视图数据应该填充在控制器中，控制器本身应该从服务中获取数据，使域对象以有意义的方式进行交互，或以事务方式命中数据库。