JavaEE 和 CDI：理解 @Observes
我有原型 org.jboss.weld.archetypes:jboss-javaee6-webapp:1.0.1.CR2 并且我尝试理解类 MemberListProducer：
@RequestScoped
public class MemberListProducer
{
@Inject @MemberRepository private EntityManager em;
private List<Member> members;
@Produces @Named public List<Member> getMembers() {return members;}
public void onMemberListChanged(@Observes(notifyObserver = Reception.IF_EXISTS)
final Member member){
retrieveAllMembersOrderedByName();
}
@PostConstruct
public void retrieveAllMembersOrderedByName()
{
//Criteria Query to fetch all members
members = em.createQuery(criteria).getResultList();
}
}
观察者被调用从另一个带有 memberEventSrc.fire(newMember); 的类来看，这似乎很清楚：一旦触发，MemberListProducer 就会更新成员名单。
但我不明白为什么这是在 @RequestScoped Bean 中完成的。根据我的理解，每个请求都会调用方法 retrieveAllMembersOrderedByName 。这个@Observes是否应该更好地放置在@ViewScoped或@SessionScoped Bean中？在这种情况下它有效果吗？
I have the archetype org.jboss.weld.archetypes:jboss-javaee6-webapp:1.0.1.CR2 and I try to understand the class MemberListProducer:
@RequestScoped
public class MemberListProducer
{
@Inject @MemberRepository private EntityManager em;
private List<Member> members;
@Produces @Named public List<Member> getMembers() {return members;}
public void onMemberListChanged(@Observes(notifyObserver = Reception.IF_EXISTS)
final Member member){
retrieveAllMembersOrderedByName();
}
@PostConstruct
public void retrieveAllMembersOrderedByName()
{
//Criteria Query to fetch all members
members = em.createQuery(criteria).getResultList();
}
}
The observer is invoked from another class with memberEventSrc.fire(newMember);, this seems clear: Once fired, the MemberListProducer updates the list of members.
But I don't understand why this is done in a @RequestScoped Bean. In my understanding the method retrieveAllMembersOrderedByName is anyway called by each request. Should this @Observes not be better placed in a @ViewScoped or @SessionScoped Bean? Does it have an effect in this case at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
@Observes 的使用更多的是一个例子，而不是一个真实的、实际的用例。在做出回应之前，请考虑成员发生变化的可能性。
我认为如果您将其删除，该网站将无法正常工作。可以这样想：
当请求开始时，将创建成员列表，并且它包含截至创建此请求作用域 bean 时的所有成员。稍后，您保留一个新成员，因此需要更新此列表以呈现响应。
当您说该列表是为每个请求构建的时，您的想法是正确的，但是这种情况发生在开始时。添加会员后，需要刷新，不是吗？
如果不存在此方法，则响应将过时（您将在保留新成员之前呈现您拥有的列表），并且您将需要一篇额外的帖子或获取新的成员列表。
@Observes像观察者模式一样解耦侦听器和事件源。因此，如果@Observes不存在，您需要将新成员显式添加到列表中，以便响应正确。我希望我正确理解你的问题。
The use of
@Observesthere is more of an example than a real, practical use case. Consider the possibility of members changing before you render your response.I don't think the website would work correctly if you removed it. Think about it like this:
When the request starts, the list of members is created and it contains all the members up to the moment of creation of this request scoped bean. Later, you persist a new member, so this list needs to be updated to render the response.
You think correctly when you say that the list is built for each request, however this happens at the beginning. After you add a member, you need to refresh it, don't you?
If this method weren't there, the response would be outdated (you'd render the list you had before you persisted the new member), and you would need one extra post or get to fetch the new list of members.
@Observesdecouples listeners and event sources much like the observer pattern. So if the@Observesisn't there, you would need to explicitly add the new member to the list so that the response is correct.I hope I understood your question correctly.
它是请求范围的，因为它存储每个请求的成员列表。如果您需要按会话存储此列表，请更改它。
但它看起来是错误的 - 您正在丢弃观察者方法的
member参数。It's request scoped because it stores a list of members per request. If you need this list to be stored per-session, then change it.
But it looks wrong - you are discarding the
memberarguments of the observer method.