Question

我想知道社区在使用Seam编程时对@BypassInterceptors注释的使用有何建议？我一直在阅读增加Seam应用程序性能，并且每篇文章都提到添加此注释可以提高性能。我的问题是，应该在哪里应用？是否有一般规则说“在编写执行XXX的组件时，您可以安全地应用@BypassInterceptors”？例如，我应该将它应用于我的实体类吗？ DAO怎么样？我非常想知道其他所有人在做什么，以及你在正确应用它时看到的性能提升。

Answer 1

如果您确定，则不需要拦截器功能，您可以依赖@BypassInterceptor注释来禁用拦截器。功能包括

Bi-jection（@In - @Out）
交易管理
Event handling

等等......

因为通过使用反射（运行时）来实现双向功能 - 例如，请参阅此question，您可以了解反射可以添加多少性能开销 - 可以避免（除了@） BypassInterceptor）使用

•Component.getInstance（＆lt; COMPONENT_NAME_GOES_HERE＆gt;）

•getter和setter的

如果你有

@Name("personManager")
public class PersonManager {

    private @In Person person;

}

<h:inputText value="#{person.name}"/>

您可以而不是@In注释

@Name("personManager")
public class PersonManager {

    private Person person;

    public Person getPerson() {return this.person;}
    public void setPerson(Person person) {this.person = person;}

}

但不要忘记（注意其最新的值属性）

<h:inputText value="#{personManager.person.name}"/>

Answer 2

只是跟随亚瑟的帖子。

根据经验，例如，如果您正在对不使用Seam中的任何拦截器的方法进行一些计算，即：计算某些值，那么用{标记该方法是一件好事{1}}。

但是在添加此注释后总是彻底测试。我遇到了一些奇怪的错误，因为我对初始测试中没有出现的方法和类有这个注释。

如果您不确切知道自己在做什么或注释正在做什么，那就更明智了。

Answer 3

Dan Allen（Seam in Action）关于这个主题的必读文章是here (part 1)和here (part 2)。它涵盖了@BypassInterceptors和Seam应用程序中的许多其他与性能相关的问题，例如条件渲染。

SEAM：有效使用@BypassInterceptors？

3 个答案: