¿Se eliminarán las inyecciones de costura?

Question

Jacob Orshalick (autor de Seam Framework: La experiencia de la Evolución de Java EE) dijo:

Outjection le permite realizar las variables disponibles en el contexto actual para inyección o acceso a través de EL. Esto puede ser beneficioso si desea acoplar libremente varios componentes que inyectan la misma variable de contexto (como el usuario actual, el hotel que se está reservando, etc.). Si quiere evitar la proyección, una alternativa es usar un método @Factory o establecer el valor directamente en el contexto a través de: Contexts.getConversationContext(). Set ("myVarName", myVar)

Otro beneficio es el rendimiento. Al proyectar un valor al contexto, puede omitir tener que pasar por su componente para obtener ese valor. Esto es especialmente aplicable en el caso de tablas de datos con JSF (ver esta discusión). Pero, como verá en la discusión, también podría usar @BypassInterceptors para lograr el mismo beneficio.

La inyección es realmente una conveniencia, pero los mismos beneficios definitivamente se pueden lograr a través de otros medios. Tenga en cuenta que la inyección no se incluyó en Web Beans y que se eliminará o se eliminará por completo en Seam 3, por lo que esta es una razón más para evitarla cuando sea posible.

Tenemos una aplicación con muchas inyecciones y comenzamos a deshacernos de ellas. Dijo:

pero los mismos beneficios definitivamente se pueden lograr a través de otros medios.

pero ¿cuáles son estos otros medios? ¿Cómo eliminar las inyecciones? En ASP.NET, por ejemplo, tiene variables de sesión. En Seam, puede expulsar var en sesión (un beneficio en algunas situaciones).

O ámbito de página: (por ejemplo, en el ciclo jsf, el bean de respaldo se llama varias veces (a veces). Tiene una cuenta cargada desde un param de página accountId. Puede cargar la cuenta, rechazarla con un alcance de página y puede usar sus propiedades en gran medida. O (para evitar la proyección) es tener un método loadAccount() donde toma la cuenta del DB siempre que lo necesite ... PEOR!)

No creo que:

Contexts.getConversationContext().set("myVarName", myVar) 

es un método de cómo evitar la proyección.

Esto solo llama al mismo contexto donde se guarda la variable expuesta y la modifica de manera profunda (creo que es exactamente lo que @Out hace en el fondo).

Pregunta 1: ¿Qué piensas chicos sobre su intención? ¿Tiene información específica sobre cómo lo reemplazarán?

Pregunta 2: ¿Cómo se puede evitar el uso de la inyección?

Gracias de antemano.

Answer 1

Creo que la mejor manera de lograr la "proyección" es mediante @Factory.Su ventaja:

• Puede ser @ Dentro de la proyectada en otro componente
• Se puede crear cualquier valor, no sólo instancia de componente
• Es calcular el valor de una vez y sólo una vez
• Puede ser desencadenada por la página JSF (no estoy seguro de si se debe habilitar la costura de gestión de transacciones con el fin de obtener esta característica)

Así que si usted tiene una página JSF que necesita acceder a un @Factory más de una vez, es calculado solo onc mi. Si es necesario calcular un valor cada vez que se solicita, entonces necesita un método @Unwrap. Por ejemplo, # {currentDate} se implementa componente integrado de la siguiente manera

@Name("org.jboss.seam.faces.facesContext") 
@Scope(ScopeType.STATELESS) // ScopeType.STATELESS is similar to Spring prototype scope 
public class CurrentDate { 
    @Unwrap 
    public Date getCurrentDate() { 
     return new java.sql.Date(System.currentTimeMillis()); 
    } 
} 

cordiales,

Answer 2

Para evitar outjection sólo tiene que añadir un captador con su campo en su bean de respaldo, así que en vez de:

@Name("myBean") 
public class MyBean{ 
    @Out 
    private SomeBean someBean; 

} 

tendrá:

@Name("myBean") 
public class MyBean{ 
    private SomeBean someBean; 

    public SomeBean getSomeBean(){ 
     return someBean; 
    } 
} 

y en su XHTML presentar/JSP tendrá que llame al getter en su lugar, pero esto también tiene algunos problemas porque cada vez que llame al getter se aplicarán todos los Seam Interceptors a esa llamada, por lo que probablemente necesite agregar @BypassInterceptors para evitar que esto suceda.

Y sí, yo también creo que

Contexts.getConversationContext().set("myVarName", myVar) 

sólo está haciendo lo que hace, pero outject manualmente.