Servicios en Symfony2

Extracto de la transcripción automática del vídeo realizada por YouTube.

sí no bueno pues buenas tardes a todos y gracias por venir a esta charla de servicio en sonidos la verdad es que la hora es un poco así después de comer y bueno intentaremos que no nos durmamos es un tema un poco espeso quizá pero voy a intentar hacerlo un

poco ameno pues espero que así sea pues bueno vamos a comenzar antes que nada agradecer evidentemente a todos los sponsors ya los organizadores porque sin ellos no podríamos venir aquí a explicar los proyectos que estamos haciendo y al final no podríamos disfrutar

todos de estos eventos y las paellas también sí que está bastante buena el arroz pero una misma gusta bastante bueno me voy a presentar un poco para los que no me conozcáis yo me llamo ricard vengo de barcelona y actualmente aunque hace muy poquitos y trabajando

una persona más social point y básicamente nos dedicamos a hacer videojuegos para redes sociales principalmente para facebook también estamos empezando a hacer vídeo fotos el iphone y bueno básicamente hay una parte de front-end que sería el flash o el iphone

en sí que todo el backoffice está hecho sin sonidos todas las acciones del juego guardar todo eso entonces bueno un poco estoy ahí desarrollando este tipo de proyectos antes de esto había estado en y magíster en hula box que fue el primer creo el primer y

commerce hecho en symphony 2 en españa y también había estado en privalia anteriormente también soy fundador del grupo symphony barcelona uno de los fundadores y organizamos charlas intentamos cada mes cada mes y medio una cosa así y bueno tengo un blog que

intentó poner cosas de symphony dos de php etcétera y también tengo una cuenta de twitter donde a veces intenta poner cosas interesantes a veces no tanto pero luego en un poquito de todo bueno a modo de índice explicar un poco lo que vamos a ver vamos a hablar

de arquitectura orientada a servicios lo que se llama shoá que esto en el mundillo java está muy está muy asentado precisa en el mundillo php en el mundillo web cuesta un poco que la gente lo aplique bien entonces vamos a intentar explicar un poco no entrar

muy en detalle de teoría pero sí explicar cómo deberíamos hacerlo hablaremos de cómo hacer una capa de modelo en symphony 2 ya veis que cuando tengáis un back del no hay una carpeta model entonces a veces hay un poco de confusión de cómo hacer estas cosas

hablaremos de los servicios ya propiamente el symphony 2 tocaremos un poco el componente configuration ya que al final van un poco ligados de la mano como creas los servicios y cómo se inyectan los parámetros y demás es una mezcla un poco de a veces de la

configuración inicial más luego lo que le inyecta saludos a los servicios inyección de dependencia es evidentemente saldrá y comentar algunas cosas que nos ocurrían en el desarrollo de la box puntocom que eso era muy al principio empezamos a desarrollar con

la beta 3 había muy poca documentación nos encontramos con algunos problemas también en parte la culpa nuestra de que no entendíamos bien algunas cosas del framework y para que intentar que no que nos suceda lo mismo que no sociedad nosotros explicar algunas

cosas etcétera vamos a empezar un poco la primera parte que es un poco más de filosofía entonces bueno básicamente esto del psoe hay muchos libros sobre ello hay charlas de horas y horas gente debatiendo y creo que quizá una buena buena forma de presentar

esto es como lo veo yo yo veo que solo va un poco de desacoplar las cosas en vez de tener clases muy grandes con funciones de dos mil líneas hay que intentar hacer pequeñas clases que hagan poquitas cosas y las hagan bien y reducirse a eso sea lo celeste al

final son clases que están creadas para una función específica y no hay que complicar las lo que hay que hacer es inyectarle todo lo que necesitan para hacer esas cosas esto ha dicho así parece muy fácil pero no lo es tanto especialmente cuando la gente de

negociones está presionando para que desarrollamos rápido muchas veces hay que pensar un poco antes de empezar a programar y eso a veces cuesta pero hay que coger estos hábitos porque si no la verdad es que al final acabamos teniendo aplicaciones inmantenible

so practicante y mantenibles que necesitas a lo mejor 50 db lópez para tocar unir porque aquello realmente no tiene test está todo acoplado y es muy complicado de amplificar entonces la gracia de todo esto al final es que si consigues desacoplar las cosas

y encapsular las en pequeñas funcionalidades añadir más funcional funcionalidades es relativamente fácil y en teoría aunque en la práctica no siempre es así tu aplicación podría escalar a nivel de lógica prácticamente con muchos menos problemas o casi sin

problemas comparado con el paradigma normal que es nos piden algo lo hacemos a la brava todo acoplado y seguramente no lo hacemos del todo bien entonces claro todas las plataformas grandes deberían un poco usar este paradigma ya sea usando se está usando jack

ruby y rails o cualquier otro framework como cento en fin todos estos que hay por ahí en todos se puede conseguir pero la verdad es que sin sonidos lo que te da es que te lo pone muy fácil para hacer esto entonces claro evidentemente como quitado todo es tan

fácil la primera dificultad que hay con todo esto es que a diferencia de lo que es un single tom un factor y todas estas cosas son patrones de diseño te las puedes descargar las pones y bueno hay un poco que entender pero muchas veces con coger el ejemplo

de la wikipedia algún bloque un poco así que lo explique bien ya está un cambio con esto es un poco más una filosofía así que hay un patrón de diseño self service layer que es leer libros de martín fowler y demás lo explica bastante bien pero al final no es

algo que coges el código lo pongas y ya funciona es un poco más abstracto y aparte de eso al final inicialmente parece que está trabajando mucho más ahora veremos una comparación de código acoplado con desacoplado que claro al final sale muchas más líneas

y inicialmente te puede echar para atrás pero los beneficios a medio y largo plazo son muchos porque aquello es mantenible aquello estés te hable y al final es la clave para que una aplicación pueda escalar y crecer con el tiempo entonces quizá lo más importante

y a la vez más difícil es delimitar la responsabilidad de cada clase y no acoplar las y eso es muy complicado es lo que más nos cuando empezamos a pensar en este paradigma esto sería un poco lo que lo que forma parte de uno mismo luego evidentemente no trabajamos

solos normalmente trabajamos en equipos y en estos equipos muchas veces hay gente juniors que a veces quiere demostrar que él hace las cosas rápido y las hace mal pero no por culpa del pobre juniors sino porque simplemente le estás pidiendo cosas que igual

no le has explicado como debería hacerlas y peor que eso hay gente que se cree senior o que ya mucho tiempo en una empresa hacer actuar de una manera que seguramente no es la más correcta y claro esto es cuesta un poco más de convencerlos de camina este paradigma

entonces podéis encontrar también un poco bloqueos de este tipo ahora intentaré factorizar una aplicación para orientar las servicios luego claro evidentemente cuando hay una base de código de 10 años que normalmente sintes te hable es un poco arriesgado de

aplicar hay técnicas pero puede ser complicado lo bueno es que se puede hacer gradualmente bases acoplando cosas y al final pues bueno consigues acoplar quizá las partes más críticas o al menos es un poco el objetivo entonces bueno vamos a ver algo que es

muy parecido a lo que me encontré cuando empezamos con la voz la box inicialmente era un prestashop un poco tuneado los que hayáis una prestación sabréis que para abrir una tienda es muy fácil pero si lo intentas escalar y modificar la verdad es que se complica

bastante entonces bueno aquí podemos ver varios problemas quizá lo más grave sería pues que esto lo miras inicialmente dices bueno hay una clase que se llama service parece que la persona que lo ha hecho lo ha hecho orientado a objetos que ya es un que pero

claro hay cosas que no que nos están del todo bien hechas por ejemplo está usando las variables dólar pos del request un servicio debería darnos igual que venga por una petición http o que nos venga por ley donde no tendríamos los posts o todo este tipo de

cosas realmente el login y el password que necesitaría esta función se lo deberíamos pasar como argumentos no coger los de tres puestos porque así estamos prohibiendo que éstos ejecuten cele y lo estamos acoplando ya que sea un servicio o sea un servicio en

una petición http peor incluso hacer este de aquí este servicio lo mejor le está llamando otro servicio que a su vez lo llama otros servicios que lo llaman controles por aquí a veces esto en producción de peta y no sabes realmente donde te están vetando a

veces te da un mensaje pero si es algo como esto aún no puedes encontrar pero en prestación pasaba que había dais con nada entonces aquello se paraba y era un poco complicado de de jugar y de encontrar dónde está el problema también hay otro gran problema

clic fijaros que no es tanto el hecho de usar smart y que bueno te puede gustar más o menos pero ha demostrado su solvencia muchos proyectos el problema es que en un servicio tampoco deberíamos estar modificando cosas de la vista final aquí fijaros que es

un poco abstracto pero estamos cogiendo es martín y asignándole un valor a una variable un servicio no debería tocar una vista eso es responsabilidad el control el controller debería recoger argumentos del request si pensamos una petición http inyectarse nos

al servicio recogerá respuesta el servicio y el montar la vista no modificar cosas aquí porque si no también un servicio toca una cosa otro otra tienes un layout aquí que al final las cosas vienen de no sé dónde y finalmente otros dos pequeños problemas que

tiene esto es que al final estamos instancia ando aquí 12 clases que son el costo en verano de 2000 services con lo cual también están acopladas a esto si lo quisiéramos testear unitariamente ya no podríamos sólo podríamos tener funcionalmente el método login

simulando un request y esperar que aquello devolviera algo pero éstas éste 'no unitariamente el comportamiento entonces si le damos un poco la vuelta y pensamos como deberíamos hacerlo desacoplado fijaros que hay bastante más código lo que os decía ahí

parece que hay más trabajo pero al final si os fijáis básicamente lo que se ha hecho es aquí pasar los parámetros con eso ya el servicio no funciona en cl y en http como queramos no hacemos un die tiramos una excepción y ya era alguien sea el servicio de enzimas

y al control ers e incluso el front el controlador el front controller que actúan raúl y este tipo de cosas pero no estamos aquí y parando el request o parando la acción luego también la que secuestro mermó del se la estamos inyectando en el constructor al

final este servicio seguramente necesita sí o sí una clase para trabajar con la base con las tablas o el vuelo de m que trate con el customer pues bueno si lo necesitas y lo inyectamos y ya también está desacoplado y finalmente el mailer fijaros que lo que

hago es una técnica que la usábamos mucho ni magíster para re factorizar código y hacerlo test te hablé al final si lo comparamos con la slate anterior a que decíamos el new aquí dentro lo que hacemos aquí es hacer un getter que si no hemos hecho la misma

[ ... ]

Nota: se han omitido las otras 5.645 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.