Struts2 xwork 使用 hibernate 进行类型转换
在 Struts2 应用程序中转换类型的最佳方法是什么？
现在我想为我的应用程序中的某个休眠实体创建 CRUD。假设我想更改与 User 关联的 Account。只要我拥有所有正确的 getter/setter，我就可以传入带有特定值的参数 user.account.id 。
当第一次创建对象时，帐户将为空，这完全可以正常工作。这使得 ognl 创建一个新的 account 对象，并将 id 设置为传入的内容。
当尝试更改封装的 Account 对象时，就会出现问题。使用相同的 user.account.id 参数，ognl 将其解释为 getUser().getAccount().setId(param)。 Hibernate 将此解释为尝试更改主键。
我明白为什么会这样做，我只是想知道是否有更好的方法来处理这种情况。这在我们的应用程序中很常见，我不想在通过休眠保存它们之前继续创建多个对象并整理它们。
有谁没有更好的方法来解决struts2中的这个问题吗？
What is the best way to convert types in a Struts2 application?
Right now I want to create a CRUD for a certain hibernate entity in my application. Say I wanted to change the Account that a User is associated with. I can just pass in the parameter user.account.id with a specific value, provided that I have all of the proper getters/setters.
This works perfectly fine when creating an object for the first time, where the account would be null. This makes ognl create a new account object, and set the id to what was passed in.
The problem happens when trying to change the encapsulated Account object. Using the same user.account.id parameter, ognl interprets this as getUser().getAccount().setId(param). Hibernate interprets this as an attempt to change the primary key.
I understand why it does this, I am just wondering if there is better way for handling this case. This is very common in our application, and I don't want to have to keep creating multiple objects and marshaling them over before I save them via hibernate.
Does anyone no a better way to solve this problem in struts2?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
用于持久性的类型转换器
为实体创建类型转换器，然后仅传递
user.account，而不是user.account.id。这将调用 getUser().setAccount(account) ，并且不会给您带来麻烦。当您更新记录时，只需将
user.account作为表单中的隐藏字段传递即可。对于实体的广泛解决方案，您有几个选择：
多个转换器
创建一个处理大部分逻辑的抽象类型转换器，以便您为每个实体拥有一个真正轻量级的子类。在
xwork-conversion.properties中注册每个转换器。接口驱动转换器
我使用的方法是有一个名为
IdBasedJpaEntity的接口，99.9% 的实体都实现了该接口。它定义了Integer类型的getId()方法。然后，我有一个在应用程序启动时创建的JpaDAORegistry单例类。我用它注册我的每个实体，它构建每个 DAO 的单个实例（基本上是一个事实上的单例）。我有一个实体类到 DAO 实例的映射。这允许我的类型转换器为任何给定的 IdBasedJpaEntity 查找适当的 DAO 实例，从而允许我拥有一个可与实现该接口的任何实体一起使用的单个 JpaEntityConverter 类。这条路线需要预先做更多的工作，但事实证明对我来说具有高度的可重用性。Type Converters for Persistence
Create a type converter for the entity and then just pass
user.account, rather thanuser.account.id. This will invokegetUser().setAccount(account)and wont cause you the headaches.When you update the record, just pass
user.accountas a hidden field in the form.As for a widespread solution for your entities, you have a few options:
Multiple Converters
Create an abstract type converter that handles most of the logic so that you have a subclass-per-entity that is really lightweight. Register each converter in your
xwork-conversion.properties.Interface-Driven Converter
The approach that I use is that I have an interface called
IdBasedJpaEntitywhich 99.9% of my entities implement. It defines agetId()method of typeInteger. I then have aJpaDAORegistrysingleton class that I create when my app starts. I register each of my entities with it and it constructs a single instance of each DAO (basically, a de-facto singleton). I have a map of entity class to DAO instance. This allows my type converter to look up the appropriate DAO instance for any givenIdBasedJpaEntity, allowing me to have a singleJpaEntityConverterclass that works with any entity that implements the interface. This route is a little bit more work up front, but has proven highly reusable for me.