Sensei 功能亮点。图书馆范围

发表于2021年6月9日
作者:Nick Van Haver
案例研究

Sensei 功能亮点。图书馆范围

发表于2021年6月9日
作者:Nick Van Haver
查看资源
查看资源

灵活地管理依赖性

Sensei 的范围功能一直是开发人员的最爱。由于能够扩大或限制配方的应用范围,开发团队已经能够根据其组织内的个别项目和垂直领域定制其使用方法--使开发人员能够个性化他们的体验。

而且可以理解的是,它是Sensei's持续创新过程的中心。在一次关于扩大 "范围"(是的,双关语)的创新头脑风暴会议上,出现了一个问题。 

"我试图为......创建一个配方,但从x版本开始,该框架已经废弃了这个功能。我不确定创建一个配方是否有用了。你怎么看?"

当然,这并不是我们第一次犹豫是否要创建一个配方。虽然配方可能被视为提供多余的信息,但我们认为创建适用于所涉及的依赖性的有限版本的东西是有价值的。因此,我们创建了库范围。

库范围使我们能够检查项目中是否存在一个依赖关系,并有条件地应用Sensei 。在团队浏览遗留代码和依赖关系时,这提供了极大的灵活性。

你们中的许多人可能知道在 "常规设置 "下已经有了图书馆范围。那么你问这是什么?我们已经启用了YAML中的库范围,就像搜索一样。这创造了一个更好的用户体验,并且在你创建配方时不会破坏你的流程,否则你将会导航到常规设置,然后再返回来更新元数据。更多的作用域将出现在YAML中,但我们已经从图书馆作用域开始。

因此,让我们通过一个例子进一步深入了解它是如何工作的。

适用于hibernate-jpamodelgen的图书馆范围

设想一下以下情况。 

我们想创建一个Spring Web REST API,使我们能够查询一些数据。根据最佳实践,我们为我们想要查询的实体创建一个模型。接下来,我们为Hibernate ORM添加一个依赖关系,这样我们就不需要摆弄数据库结构了。ORM为我们解决了这个问题。我们还需要创建一个服务,从数据访问层(CRUD库等)向控制器提供数据。最后,我们为我们的API创建一个控制器类,在这里我们将把允许的查询作为端点公开。

为了避免为每个可查询的字段暴露不同的端点,我们选择使用JPA 2规范。为此,我们在控制器中从请求的URL中创建一个规范。这个规范描述了我们正在寻找的实体应该是什么样子的。在 "规范 "类本身,我们实现了 "toPredicate "方法,以表明如何验证该规范。

但是我们在 "toPredicate "方法中遇到了一个问题。为了构建谓词,我们需要知道数据库中要比较的列的名称。但由于我们使用的是ORM,我们没有这些列存在于一个单独的模型中。所以,Hibernate的JPA 2元模型生成器()来了!这将有助于生成元模型。这将有助于为我们要求它处理的实体生成一个元模型。这些元模型允许我们将列名作为属性引用,而不是硬编码。

创建Sensei 配方

现在我们已经生成了元模型,我们想把它们用好。Sensei ,可以帮助任何在项目上工作的人,提醒他们使用元模型,确保列名不在任何地方硬编码。所以,让我们把它付诸实践。

首先,我们看一下`toPredicate`方法

对谓语的方法

这个基本的谓词将只比较我们实体的名称。我们可以使用 "and "子句对其进行扩展,但就本食谱而言,这种 "简单 "的检查就可以了。

对于配方的搜索部分,我们想调用根参数的方法`get()`,所以我们从下拉菜单中选择`methodcall`选项。接下来,我们想把搜索限制在名称为`get'的方法调用上,其签名在`javax.persistence.criteria'包的`Path'接口中声明。由于该方法已经被重载,我们还需要告诉搜索,我们的配方只适用于以单个字符串作为参数的变体。为了解决在代码中出现列名的问题,我们希望使用一个`SingularAttribute`类型的参数,与元模型生成器提供的类型相同。

设置配方的搜索标准

到目前为止,我们创建的配方将在任何使用JPA 2 `Path`接口的代码库上触发,无论该代码库是否被设置为使用Hibernate Model Generator。如果项目中存在这个库,我们想向用户表明应该使用它,所以我们在配方中添加一个库的范围。

限制本食谱的搜索范围

最后,我们的食谱现在已经准备好了。

测试配方方法call

有了这个配方,任何使用字符串值作为参数的`Path#get`的出现都会被标记。从上面截图中突出显示的示例代码可以看出,当列名的字面名称被存储在一个中间变量中时,这个配方仍然有效。

注意 - 我们也可以反转库的作用域来处理库不可用的情况,方法是在作用域前加一个`not`子句。

总结

正如我们在上面的例子中所看到的,这个新功能使我们能够根据项目中存在的依赖关系来应用它们,从而创建更有用的配方。为了进一步加强它的功能,我们包括了比例子中显示的更多的选项,比如不仅要检查依赖关系是否存在,还要对依赖关系的特定版本施加条件。 

我们看到这个功能的主要用例是防止配方提供重复的信息,检测与特定版本的依赖关系有关的问题,但也可以执行从一个依赖关系版本到下一个版本的迁移。我们期待着听到你对这项功能的使用。

至于所有的Sensei 功能,关于库的范围的更多信息可以在参考文件中找到。

查看资源
查看资源

作者

尼克-范-哈弗

想要更多吗?

在博客上深入了解我们最新的安全编码见解。

我们广泛的资源库旨在增强人类对安全编码技术提升的方法。

查看博客
想要更多吗?

获取关于开发者驱动的安全的最新研究

我们广泛的资源库充满了有用的资源,从白皮书到网络研讨会,让你开始使用开发者驱动的安全编码。现在就去探索它。

资源中心

Sensei 功能亮点。图书馆范围

发表于2021年6月9日
作者:Nick Van Haver

灵活地管理依赖性

Sensei 的范围功能一直是开发人员的最爱。由于能够扩大或限制配方的应用范围,开发团队已经能够根据其组织内的个别项目和垂直领域定制其使用方法--使开发人员能够个性化他们的体验。

而且可以理解的是,它是Sensei's持续创新过程的中心。在一次关于扩大 "范围"(是的,双关语)的创新头脑风暴会议上,出现了一个问题。 

"我试图为......创建一个配方,但从x版本开始,该框架已经废弃了这个功能。我不确定创建一个配方是否有用了。你怎么看?"

当然,这并不是我们第一次犹豫是否要创建一个配方。虽然配方可能被视为提供多余的信息,但我们认为创建适用于所涉及的依赖性的有限版本的东西是有价值的。因此,我们创建了库范围。

库范围使我们能够检查项目中是否存在一个依赖关系,并有条件地应用Sensei 。在团队浏览遗留代码和依赖关系时,这提供了极大的灵活性。

你们中的许多人可能知道在 "常规设置 "下已经有了图书馆范围。那么你问这是什么?我们已经启用了YAML中的库范围,就像搜索一样。这创造了一个更好的用户体验,并且在你创建配方时不会破坏你的流程,否则你将会导航到常规设置,然后再返回来更新元数据。更多的作用域将出现在YAML中,但我们已经从图书馆作用域开始。

因此,让我们通过一个例子进一步深入了解它是如何工作的。

适用于hibernate-jpamodelgen的图书馆范围

设想一下以下情况。 

我们想创建一个Spring Web REST API,使我们能够查询一些数据。根据最佳实践,我们为我们想要查询的实体创建一个模型。接下来,我们为Hibernate ORM添加一个依赖关系,这样我们就不需要摆弄数据库结构了。ORM为我们解决了这个问题。我们还需要创建一个服务,从数据访问层(CRUD库等)向控制器提供数据。最后,我们为我们的API创建一个控制器类,在这里我们将把允许的查询作为端点公开。

为了避免为每个可查询的字段暴露不同的端点,我们选择使用JPA 2规范。为此,我们在控制器中从请求的URL中创建一个规范。这个规范描述了我们正在寻找的实体应该是什么样子的。在 "规范 "类本身,我们实现了 "toPredicate "方法,以表明如何验证该规范。

但是我们在 "toPredicate "方法中遇到了一个问题。为了构建谓词,我们需要知道数据库中要比较的列的名称。但由于我们使用的是ORM,我们没有这些列存在于一个单独的模型中。所以,Hibernate的JPA 2元模型生成器()来了!这将有助于生成元模型。这将有助于为我们要求它处理的实体生成一个元模型。这些元模型允许我们将列名作为属性引用,而不是硬编码。

创建Sensei 配方

现在我们已经生成了元模型,我们想把它们用好。Sensei ,可以帮助任何在项目上工作的人,提醒他们使用元模型,确保列名不在任何地方硬编码。所以,让我们把它付诸实践。

首先,我们看一下`toPredicate`方法

对谓语的方法

这个基本的谓词将只比较我们实体的名称。我们可以使用 "and "子句对其进行扩展,但就本食谱而言,这种 "简单 "的检查就可以了。

对于配方的搜索部分,我们想调用根参数的方法`get()`,所以我们从下拉菜单中选择`methodcall`选项。接下来,我们想把搜索限制在名称为`get'的方法调用上,其签名在`javax.persistence.criteria'包的`Path'接口中声明。由于该方法已经被重载,我们还需要告诉搜索,我们的配方只适用于以单个字符串作为参数的变体。为了解决在代码中出现列名的问题,我们希望使用一个`SingularAttribute`类型的参数,与元模型生成器提供的类型相同。

设置配方的搜索标准

到目前为止,我们创建的配方将在任何使用JPA 2 `Path`接口的代码库上触发,无论该代码库是否被设置为使用Hibernate Model Generator。如果项目中存在这个库,我们想向用户表明应该使用它,所以我们在配方中添加一个库的范围。

限制本食谱的搜索范围

最后,我们的食谱现在已经准备好了。

测试配方方法call

有了这个配方,任何使用字符串值作为参数的`Path#get`的出现都会被标记。从上面截图中突出显示的示例代码可以看出,当列名的字面名称被存储在一个中间变量中时,这个配方仍然有效。

注意 - 我们也可以反转库的作用域来处理库不可用的情况,方法是在作用域前加一个`not`子句。

总结

正如我们在上面的例子中所看到的,这个新功能使我们能够根据项目中存在的依赖关系来应用它们,从而创建更有用的配方。为了进一步加强它的功能,我们包括了比例子中显示的更多的选项,比如不仅要检查依赖关系是否存在,还要对依赖关系的特定版本施加条件。 

我们看到这个功能的主要用例是防止配方提供重复的信息,检测与特定版本的依赖关系有关的问题,但也可以执行从一个依赖关系版本到下一个版本的迁移。我们期待着听到你对这项功能的使用。

至于所有的Sensei 功能,关于库的范围的更多信息可以在参考文件中找到。

我们希望得到您的许可,向您发送有关我们产品和/或相关安全编码主题的信息。我们将始终以最谨慎的态度对待您的个人资料,绝不会将其出售给其他公司用于营销目的。

要提交表格,请启用 "分析 "cookies。完成后,请随时再次禁用它们。