范围类型如何影响 EntityQuery 对象的重用方式

for (...) {
    UserList userList = (UserList) Component.getInstance(UserList.class, ScopeType.METHOD);
    userList.getUserByEmailAddress(emailId);
}

Seam 支持不同的 ScopeType（例如 METHOD、PAGE、EVENT、APPLICATION）。我们当前使用 METHOD 范围通过电子邮件 ID 检索用户对象。上面的代码存在于 for 循环中（即，对于用户电子邮件地址的集合，我们检索用户对象）。这是正确的 ScopeType 还是最好将 UserList 声明移至 for 循环上方

我们观察到在某些范围类型中 userList 对象被重用，有人可以澄清它的真正工作原理吗？ Seam 中是否有任何工具可以帮助您了解如何重用这些对象（我们打开了一些跟踪日志记录，但正在进行的调用太多，而且不太清楚）

ScopeType.METHOD 说

每次调用会话 Bean 或 JavaBean 组件将新的方法上下文放入与当前线程关联的方法上下文堆栈中。当方法返回时，上下文被破坏。

Seam 的大部分功能都是作为一组内置 Seam 拦截器实现的。这是 API 所说的 MethodContextInterceptor （内置 Seam 拦截器）的一段代码

设置 METHOD 上下文并在通话期间取消 SFSB 的代理

MethodContextInterceptor.java 请参阅下面的注释并与上面突出显示的文本进行比较

@AroundInvoke
public Object aroundInvoke(InvocationContext ctx) throws Exception {
    Component comp = getComponent();

    String name = comp.getName();
    Object target = ctx.getTarget();
    Method method = ctx.getMethod();
    Object[] parameters = ctx.getParameters();

    /**
      * beginMethod
      *
      * Takes care of putting a NEW method context onto the stack of method contexts
      */
    Context outerMethodContext = Lifecycle.beginMethod();

    try {
        Contexts.getMethodContext().set(name, target);
        Contexts.getMethodContext().set("org.jboss.seam.this", target);
        Contexts.getMethodContext().set("org.jboss.seam.method", method);
        Contexts.getMethodContext().set("org.jboss.seam.parameters", parameters);
        Contexts.getMethodContext().set("org.jboss.seam.component", comp);

        /**
          * And after method return 
          */ 
        return ctx.proceed();
    } finally {
        /**
          * endMethod Takes care of destroying The previous added method context
          */       
        Lifecycle.endMethod(outerMethodContext);
    }
}

正如您所看到的，我没有看到 ScopeType.METHOD 提供的任何特殊行为。我认为 Seam 项目的创始人 Gavin King 创建了 ScopeType.METHOD 作为可以在以后使用的附加范围。即使 Seam in Action 一书也不涵盖 ScopeType.METHOD 范围。

所以每次你打电话的时候通过电子邮件地址获取用户，执行上面的例程。关于上下文，Seam in Action 书很清楚

上下文定义了可以找到变量名的位置以及它存在多久

因此，您所需的范围应该符合您的业务需求。

关于实体查询？？？这是 Seam in Action 书中所说的内容

如果执行查询每次你需要展示结果时，你都可以撤消pressure在数据库上。在另一个极端，如果你保留结果太久，你最终会向用户提供stale信息这可能会让他们感到困惑，或更糟糕的是，导致他们做出错误的决定。

默认情况下，某些 Query 方法会避免冗余的数据库查询通过将结果缓存在私有财产中在课堂上。但它可以被覆盖，因为你改变了

• 查询限制参数
• 排序顺序
• 最大结果值
• 第一个结果偏移量
• 通过调用refresh()手动清除结果

当您更新某些 @Entity 并且需要刷新存储的结果集时，最后一项很有用。您可以通过使用 Seam 事件来完成它。但如果你总是想要一个新的结果集，将 EntityQuery 设置为 ScopeType.EVENT 并在 for 循环之前使用它

UserList userList = (UserList) Component.getInstance(UserList.class, ScopeType.EVENT);
for (...) {
    userList.getUserByEmailAddress(emailId);
}

这是 Seam 和 Spring 范围之间的并排比较

Seam                               Spring            Suited for
ScopeType.STATELESS                singleton         Service, repositories, Thread-safe components
ScopeType.APPLICATION              singleton         Service, repositories, Thread-safe components
ScopeType.SESSION                  session           User login
ScopeType.CONVERSATION             -                 Page flow
ScopeType.PAGE                     -                 Server-side based component model
ScopeType.EVENT                    request           Non Thread-safe components

注意 ScopeType.CONVERSATION 不等于 Spring web flow。 Seam ScopeType.CONVERSATION 超越了 Web 层。甚至持久性上下文也可以包含在对话上下文中。请记住，当您拥有基于服务器端的组件模型框架（例如 JSF、Wicket 等）时，ScopeType.PAGE 才有意义。通常，当您拥有完全 Java EE 环境时，将使用 ScopeType.STATELESS，而当您拥有完全 Java EE 环境时，将使用 ScopeType.APPLICATION。您使用普通 POJO 而不是 EJB。