Arena - ApplicationContext

Al construir una aplicación es frecuente trabajar con objetos a los que nos resultaría cómodo accederlos desde cualquier contexto:

• los repositorios o homes
• objetos que almacenan configuraciones (como el envío de mails)
• etc.

El patrón Singleton nos permite ofrecer un único punto de acceso para este tipo de objetos desde el ambiente, algo que resulta sin dudas muy cómodo. Supongamos que tenemos una aplicación de ventas que permite agregar nuevos productos a vender (entre otras cosas, también permite registrar una venta). La vista tiene como modelo un application model que conoce un repositorio de Ventas que logra este objetivo:

Cuando generemos el test para ese application model sobre la funcionalidad crearProducto, estamos obligados a utilizar la implementación del repositorio de ventas (no es posible mockear el repositorio, y en general es el problema que tienen los singletons).

El siguiente gráfico muestra cómo es la relación de los objetos:

Arena implementa un objeto ApplicationContext que resuelve el inconveniente que comentamos anteriormente. Para eso trabaja con la técnica del Service Locator (que surge como una técnica para la Inyección de dependencias, el lector interesado puede profundizar su estudio en este apunte).

La interfaz que publica es la siguiente:

Recomendamos utilizar el par de métodos

• configureSingleton y
• getSingleton

que se utilizan para almacenar y recuperar respectivamente objetos singleton.

Al comenzar la aplicación, debemos crear los repositorios y hacer que el application context los referencie. ¿Dónde configurar los repositorios?

1) Una opción es que lo haga la *Application cuando crea la ventana principal

2) Otra opción es que haya un Bootstrap que se encargue de generar el juego de datos. Entonces podría ser que en el constructor se inicialicen los repositorios necesarios.

Por su parte, el test puede configurar en un método de inicialización un repositorio mockeado:

El Application Model obtiene el home a partir del singleton Application Context:

Esto permite que el objeto application model trabaje con un repositorio sin saber si es el real (para la aplicación) o un impostor / mock (para el test).

A continuación vemos el gráfico que explica cómo quedan las referencias: