go - 在整洁的架构设置中使用 gorm 时是否需要持久性模型？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

去年关闭。




Improve this question




在 clean architecture软件方法实体是最内层，不应该依赖于像 ORM 这样的东西。
为方便起见，我想在我的项目中使用 ORM，而 gorm 似乎是一个流行的库。在 gorm docs推荐的使用方法是使用 gorm.Model struct包含在要持久保存在数据库中的结构中。
当尝试在我的项目中使用 gorm 并遵循干净的架构时，我最终得到了一个映射层，该映射层将我的实体与特定于 gorm 的持久性模型进行映射，以使 gorm 依赖于我的实体。这似乎消除了使用 ORM 的所有好处，例如这个blog post被明确警告。
在我看来，在遵循干净架构的同时避免映射层只能通过使用侵入性较小的 ORM 甚至只是一个 sql 扩展来实现，例如sqlx我可以在哪里直接使用我的实体？

Answer 1

我感觉这个问题更适合 Software Engineering SE但我会尝试回答。
对您的问题的简短回答是:是的。
如果您想完全遵循 Clean Architecture，那么要做的就是构建完全不依赖于您的持久层的域模型。使用 gorm，这需要构建域 <-> 持久性模型映射层以及由此产生的所有附加复杂性。 Gorm 仍然会使查询和保存该持久性模型比创建您自己的查询更容易，并且与我体验过的其他语言的 ORM 相比，它仍然相当轻量级。
从技术上讲，您不需要 gorm.Model在模型结构中。拥有 ID int字段，加上任何 CreatedAt , UpdatedAt , DeletedAt你想要的字段就足够了(这就是 gorm.Model 给你的)。但是你总是会添加其他与 gorm 做事方式有关的工件，所以如果 gorm包不存在于您的模型结构中。
但
这就引出了一个问题，即遵循 Clean Arch 是否是您项目的正确决定。与所有设计决策一样，它需要权衡取舍，并且根据所构建系统的范围和复杂性或多或少有意义。如果您预见到您的项目将遇到的挑战 Clean Arch 可以缓解，那么现在额外的投资将得到返回。另一方面，如果架构的某些方面可以缓解您在特定情况下不太可能遇到的问题，那么您可能会更加宽容。您链接的博客文章的结论也提出了相同的论点:

NHibernate provides the best set of trade-offs between theimplementation complexity and the overall purity. There still will beORM concerns leaking into your domain model, however. But I think it’sa low price for all the benefits you’ll get out of it: speed ofdevelopment, rich functionality, and separation of concerns.