POJO或DTO方法

Question

我正在使用Struts2、Spring和Hibernate作为核心构建块开发一个新的Web应用程序。

我们已经根据Hibernate映射文件创建了POJO类。用户会提供一些需要更新到底层数据库的输入。

例如注册或更新。

我们有几个选项，比如为动作类创建新的POJO/DTO，由Struts2填充，然后将它们传输到服务层，在那里我们可以将这些DTO转换为相应的Hibernate POJO，否则我们可以将同样的POJO暴露给Struts2，以便框架可以用用户输入填充它们，我们不需要进行转换和创建额外的类。

应用程序不会很大，中等大小的应用程序标记。

我的问题是，将此用户输入传输到底层Hibernate层以执行特定于数据库的工作的最佳方法是什么？

提前感谢您。

- Umesh Awasthi

Answer 1

针对这种情况，我建议采用“数据传输对象（DTO）”的方式，这样你就可以先验证输入并只在需要时触发更新。

不过，你也可以将分离的实体作为DTO，并在创建或更新时重新附加它们。如果你不希望应用程序的 Web 部分依赖于 Hibernate 和/或 JPA，那么你可能需要创建另一组类（除非你不使用任何一个注释）。

- Thomas

---

使用附加实体作为来自的数据接收器是危险的，因为它可能会在没有显式保存的情况下触发数据库更新（或者Hibernate团队已经解决了这个问题吗？） - Konstantin Pribluda

@KonstantinPribluda 没错，这就是为什么我更喜欢“DTO”方法 - 即使DTO实际上是_分离的_实体。 - Thomas

几年来，我的屁股差点被咬掉了 - 我想这是在次要的Hibernate版本中引入的更改 ;) - Konstantin Pribluda

@Thomas，我也倾向于DTO方法，感谢您宝贵的建议。 - Umesh Awasthi

Answer 2

你会在这里得到两个答案。

对于Struts 2，我倾向于使用普通的S2操作属性来收集表单值等，并使用BeanUtils将它们复制到Hibernate对象中。将Hibernate对象暴露给表单的问题，例如使用ModelDriven等，是如果您有不应该由用户直接设置的列，则需要定义白名单/黑名单。 （或以不同的方式处理问题。）

话虽如此，我并不像很多人那样根本反对这个想法，他们可以说是正确的。

- Dave Newton

---

同意，但在某些情况下，我有大量的属性，将属性放在操作类中就像让操作类非常拥挤。 - Umesh Awasthi

@user702325 然后您可以使用Hibernate模型，或者使用源代码生成创建仅包含所需属性的POJO，并使用ModelDriven。我不确定您真正想要问什么，我猜您可以使用动作本身或模型。看起来您已经决定走哪条路了。 - Dave Newton

我还没有想出任何东西，但我知道在操作层使用Hibernate POJO的问题，所以我有点倾向于为操作层创建DTO/POJO，然后将它们映射到Hibernate POJO。 - Umesh Awasthi