Este documento presenta los conceptos de arquitectura orientada a servicios y cómo se implementan en Symfony2. Explica que la capa de modelo en Symfony2 se compone principalmente de servicios en lugar de clases de modelo, y proporciona ejemplos de cómo crear y configurar servicios, incluida la inyección de dependencias y el uso de etiquetas de servicio. También cubre temas avanzados como servicios abstractos, fábricas de servicios y la arquitectura de servicios para aplicaciones complejas.

3. Hello World
• Ricard Clau Pintado
• Trabajo en SocialPoint
• Antes en Emagister, Ulabox y Privalia
• Fundador Symfony-Barcelona
• Blogger http://www.ricardclau.com
• Twitter @ricardclau

4. ¿Qué vamos a ver?
• Arquitectura orientada a servicios (SOA)
• La capa de modelo en Symfony2
• Servicios en Symfony2
• Componente Configuration
• Inyección de dependencias
• Experiencias en el desarrollo de Ulabox.com

5. Arquitectura SOA
Teoría y filosofía

6. El concepto SOA
• Arquitectura Orientada a Servicios
• Los Servicios son clases creadas para desarrollar una
función específica y se pueden utilizar en cualquier punto
de nuestra aplicación.
• Encapsulando la lógica de negocio en servicios podemos
desacoplar las clases de nuestra aplicación, que podrá
crecer “sin problemas”
• Todas las plataformas grandes lo usan (o deberían)

7. No todo es tan fácil
• Es una filosofía entorno al patrón de diseño Service Layer
• Parece que estamos trabajando más
• Es muy importante delimitar la responsabilidad de cada
servicio y no acoplarlos
• Hay que concienciar a todo el equipo, formar a los juniors
y convencer a la gente con malos hábitos
• Puede ser complicado de aplicar en código legado
• Pero... ¡se puede hacer gradualmente!

8. Servicios acoplados

9. Servicios desacoplados :)

10. El modelo en Symfony2
Introducción a los servicios

11. La evolución del MVC
• Symfony2 no es un framework MVC estrictamente
• De hecho, la carpeta “Model” no existe por defecto!
• Es tan flexible que nos da la libertad de construir la capa
de Modelo como convenga a nuestra aplicación
• Y eso puede ser peligroso...

12. Y entonces... ¿Doctrine2?
• Doctrine2 abstrae el acceso al sistema de
almacenamiento, tanto SQL como algunos No-SQL
• Las “Entities” mapean tablas (ORM) / documentos (ODM)
• Los “Repositories” permiten encapsular operaciones y
realizar consultas algo más complejas
• Pero ahí no debería ir la lógica de negocio!

13. El modelo en Symfony2
• En Symfony2, más que hablar del modelo, podemos
hablar de la capa de servicios
• Hay que evitar los controllers de 2000 líneas
• En los repositories no deberíamos poner lógica de
negocio, son para querys complejas
• Las vistas deben tener la mínima lógica posible
• Cada servicio debe recibir sólo lo que necesita y exponer
unas interficies claras para su uso. Nunca usar el Request
ni modificar la Response.

14. Servicios en Symfony2
Ejemplos prácticos

15. Servicios en Symfony2
• Muchos de los componentes de Symfony2 están
disponibles como servicios
• Algunos: Doctrine2 Entity Manager, Swiftmailer,
Validator, Translator, Templating, Routing, ...
• Muchos bundles añaden nuevos servicios y podemos
crear nuestros propios servicios!
• Acceso mediante el “Dependency Injection Container”
desde las clases con interface “ContainerAware”

16. Listado de servicios
• php app/console container:debug

17. ¿Qué tengo en el container?
• https://github.com/Elao/WebProfilerExtraBundle

18. Debug del container (I)
• https://github.com/schmittjoh/JMSDebuggingBundle

19. Debug del container (II)
• https://github.com/schmittjoh/JMSDebuggingBundle

20. Validator Service

21. Mailer Service

22. Configurando la aplicación
Carga de nodos y inyección al container

23. Configuraciones en Symfony2
• app/config -> aplicación Resources/config -> Bundles
• Configuración base que extendemos para el resto de
entornos
• Conveniente separarlo en varios archivos

24. [parameters]
• Se suelen definir constantes de configuración
• Permite que cada usuario tenga el setup como quiera
• Los valores bajo la clave [parameters] se inyectan en el
container directamente. Podemos usarlos en otras
secciones con %valor%
• Podemos crear nuestras propias claves para configurar
nuestros bundles, que deberán ser leídas en los archivos
de la carpeta DependencyInjection

25. Configuración compleja
• Se inyecta bien pero no tenemos validación!

26. Bundle complejo -> a validar!
• Creamos los parámetros bajo la clave de nuestro bundle

27. TreeBuilder
• Creamos un TreeBuilder en una clase Configuration
dentro de la carpeta DependencyInjection

28. Validando parámetros texto

29. Validando estructura array

30. Jugueteando con el array

31. Exprimiendo el componente!

32. BundleExtension
• Inyectamos la configuración en la Extension:

33. Creación de servicios
Inyección de dependencias

34. Hello world Servicios
• Servicio para recuperar información de Sensio Connect!

35. Config y uso del servicio
• En el config de la aplicación
• Modificamos services.yml en Resources/config
• Y desde el controller

36. Dependencias de un servicio
• Un servicio puede depender de parámetros de
configuración y/o de otros servicios
• Nos referimos a los parámetros con %param% y los
servicios con @nombre_servicio
• Constructor Injection -> arguments:

37. Dependencias opcionales
• Setter Injection y otras inicializaciones -> calls
• Podemos combinarlo todo en servicios complejos

38. Antipattern: setContainer

39. Aplicaciones complejas
Servicios parent, factories y tags

40. Servicios abstract / parent

41. Service Factories
• El mejor ejemplo son los repositories
• Pero si hacemos esto
• Los controllers quedan así de limpios!

42. Service Tags (I)
• Agrupación de servicios
• El tag en sí no significa nada pero puede ser útil para
extender componentes con nuevos loaders / adapters.
Suelen procesarse en las CompilerPass
• Lo usamos en Twig para cargar extensiones

43. Service Tags (II)
• El componente Translator lo usa para los loaders
• O cuando necesitamos crear un Event Listener

44. E-commerce con servicios
Web Backoffice API (Iphone, ...)
KernelController Listeners / Before hooks (autenticaciones, ...)
Controllers ligeros que traducen Request a parámetros
Servicios de primer nivel / unidades de negocio M
(Customer, Cart, Order, Catalogue)
O
Servicios auxiliares a modo de Helpers
(Logger, Translator, Validator, Mailer, ...)
D
Interacción Storage / 3rd party
E
(Entities, Repositories, Solarium, PRedis, OpenInviter...) L
BBDD No-SQL / Caches 3rd Party APIs

45. Agradecimientos
• A los Ulaboxers PHPeros: Sergi, Albert, Marc
• Al equipo #rigor de @EmagisterTech
• A la organización y sponsors de DeSymfony
• A todos vosotros :)

46. ¿Preguntas?
• E-mail: ricard.clau@gmail.com
• Twitter: @ricardclau
• Github: https://github.com/ricardclau
• O si os da corte ahora... en otro momento :)