Inyectando dependencias para remover lógica de un controlador de Rails
En los proyectos que me ha tocado trabajar y algunos que he visto por ahí, es normal tener un poco de lógica de negocio en el controlador.
El problema con esto es que a veces un controlador es difícil de probar porque correr las pruebas cargando Rails es muy lento!! (bueno tal vez es muy lento para mi). Y otro problema es que si eres como yo, tal vez prefieres tener la lógica de negocio centralizada y no con ciertas partes en el modelo, otras en el controlador y otras en alguna clase que hayas creado por ahí.
A mi en lo personal me gusta tener la lógica de negocio en objetos que no tienen nada que ver con Rails o con algún otro framework. De esta forma puedo tener pruebas rápidas y código más fácil de entender, porque no tiene que andar manejando otras cosas que no sean reglas de negocio.
Hace unos días me toco trabajar en guardar unos eventos que queremos medir en la aplicación…
Primer intento…
Para cierto evento, en primera instancia, decidí mandar esta información directamente desde el controlador, apoyando me de ciertas funciones que ya existen en el proyecto. Y decidí no probar nada.
El código quedo más o menos así…
Como empezamos a medir algunas cosas más, dejó de darme confianza el estar enviando la información sin probar y directamente desde el controlador.
Por lo que decidí hacer un cambio para quitar responsabilidad al controlador.
Segundo intento… transformación inyectando dependencia…
Para quitar esta responsabilidad al controlador decidí crear un nuevo objeto que tendría un método investment_intention_sent que inyectaría como configuración al método InvestmentIntentions.create_intention para que fuera ahí dentro que se llamara este nuevo método con la información correcta.
Creo que esto ayudó porque…
- Es más fácil probar que estamos mandando los datos bien.
- El controlador conoce menos de la interfaz del módulo Projects, lo que me permite cambiar ese código con más confianza.
- Me permitió posteriormente reutilizar parte de ese código para enviar la información de otro evento.
Puede que no sea el mejor diseño, pero tengo confianza en que el código funciona. Por lo que este fue el código final de esa iteración.
Al comentar sobre esto a mis compañeros en Innku vieron que otra posible opción era usar directamente el método Analytics.track… En un principio creí que era mejor mantener un nombre más específico pero al final decidí cambiarlo a como ellos mencionaron (Pero sobre eso escribiré en una siguiente oportunidad…).
¿Tienes alguna opinion?
