在使用 gorm 进行干净的架构设置时，是否需要持久性模型？

golang学习网今天将给大家带来《在使用 gorm 进行干净的架构设置时，是否需要持久性模型？》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习Golang或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

在软件的干净架构方法中，实体是最内层，不应该依赖于 ORM 之类的东西。

为了方便起见，我想在我的项目中使用 ORM，而 gorm 似乎是一个流行的库。在 gorm 文档中，推荐的使用方法是将 gorm.Model 结构包含在要保留在数据库中的结构中。

当尝试在我的项目中使用 gorm 并遵循干净的架构时，我最终得到了一个映射层，该映射层将我的实体映射到特定于 gorm 的持久性模型，以便将 gorm 依赖项排除在我的实体之外。这似乎消除了使用 ORM 的所有好处，例如这篇博文已明确警告。

在我看来，在遵循干净的架构的同时避免映射层只能通过使用侵入性较小的 ORM 甚至只是像这样的 sql 扩展来实现。 sqlx 我可以在哪里直接使用我的实体？

解决方案

我感觉这个问题更适合Software Engineering SE，但我会尝试回答。

对您问题的简短回答是：是的。

如果您想严格遵循清洁架构，那么要做的就是构建根本不依赖于持久层的域模型。对于 gorm，这需要构建一个域 <-> 持久模型映射层以及由此带来的所有增加的复杂性。 Gorm 仍将使查询和保存持久性模型比创建自己的查询更容易，并且与我体验过的其他语言的 ORM 相比，它仍然相当轻量。

从技术上讲，您不需要在模型结构中包含 gorm.Model。拥有 ID int 字段，加上您想要的任何 CreatedAt、UpdatedAt、DeletedAt 字段就足够了（这是 gorm.Model 为您提供的）。但您总是会添加与 gorm 的工作方式有关的其他工件，因此，如果您的模型结构中不存在 gorm 包，您就无法摆脱这种依赖性。

但是

这就引出了一个问题：严格遵循 Clean Arch 对于您的项目来说是否是正确的决定。与所有设计决策一样，它需要权衡，并且根据所构建系统的范围和复杂性或多或少有意义。如果您预见到您的项目将遇到 Clean Arch 可以缓解的挑战，那么现在的额外投资将会得到回报。另一方面，如果架构的某些方面可以缓解您在特定情况下不太可能遇到的问题，那么您可能会更加宽容。您链接的博客文章的结论提出了同样的论点：

NHibernate 提供了一组最佳的权衡 实现复杂性和整体纯度。还是会有 然而，ORM 担心泄漏到您的域模型中。但我认为这是 以低廉的价格获得您从中获得的所有好处：速度 开发、丰富的功能和关注点分离。

以上就是《在使用 gorm 进行干净的架构设置时，是否需要持久性模型？》的详细内容，更多关于的资料请关注golang学习网公众号！