• Like
  • Save
Desymfony  - Servicios
Upcoming SlideShare
Loading in...5
×
 

Desymfony - Servicios

on

  • 5,483 views

Las transparencias de mi charla sobre Servicios en Symfony2 en deSymfony 2012

Las transparencias de mi charla sobre Servicios en Symfony2 en deSymfony 2012

Statistics

Views

Total Views
5,483
Views on SlideShare
2,560
Embed Views
2,923

Actions

Likes
5
Downloads
92
Comments
0

20 Embeds 2,923

http://www.symfony.es 877
http://desymfony.com 775
http://blog.liip.ch 708
https://blog.liip.ch 225
http://www.desymfony.com 141
https://twitter.com 62
http://symfony.es 58
http://desymfony.es 23
http://librosweb.es 16
http://www.linkedin.com 14
http://192.168.11.11 6
http://www.desymfony.es 4
http://www.aggregator.ch 3
http://192.168.11.10 3
http://www.newsblur.com 3
http://desymfony.local 1
http://ranksit.com 1
http://translate.googleusercontent.com 1
http://planet.freeflux.net 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Desymfony  - Servicios Desymfony - Servicios Presentation Transcript

    • Hello World• Ricard Clau Pintado• Trabajo en SocialPoint• Antes en Emagister, Ulabox y Privalia• Fundador Symfony-Barcelona• Blogger http://www.ricardclau.com• Twitter @ricardclau
    • ¿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
    • Arquitectura SOA Teoría y filosofía
    • 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)
    • 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!
    • Servicios acoplados
    • Servicios desacoplados :)
    • El modelo en Symfony2 Introducción a los servicios
    • 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...
    • 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!
    • 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.
    • Servicios en Symfony2 Ejemplos prácticos
    • 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”
    • Listado de servicios• php app/console container:debug
    • ¿Qué tengo en el container?• https://github.com/Elao/WebProfilerExtraBundle
    • Debug del container (I)• https://github.com/schmittjoh/JMSDebuggingBundle
    • Debug del container (II)• https://github.com/schmittjoh/JMSDebuggingBundle
    • Validator Service
    • Mailer Service
    • Configurando la aplicación Carga de nodos y inyección al container
    • 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
    • [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
    • Configuración compleja• Se inyecta bien pero no tenemos validación!
    • Bundle complejo -> a validar!• Creamos los parámetros bajo la clave de nuestro bundle
    • TreeBuilder• Creamos un TreeBuilder en una clase Configuration dentro de la carpeta DependencyInjection
    • Validando parámetros texto
    • Validando estructura array
    • Jugueteando con el array
    • Exprimiendo el componente!
    • BundleExtension• Inyectamos la configuración en la Extension:
    • Creación de servicios Inyección de dependencias
    • Hello world Servicios• Servicio para recuperar información de Sensio Connect!
    • Config y uso del servicio• En el config de la aplicación• Modificamos services.yml en Resources/config• Y desde el controller
    • 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:
    • Dependencias opcionales• Setter Injection y otras inicializaciones -> calls• Podemos combinarlo todo en servicios complejos
    • Antipattern: setContainer
    • Aplicaciones complejas Servicios parent, factories y tags
    • Servicios abstract / parent
    • Service Factories• El mejor ejemplo son los repositories• Pero si hacemos esto• Los controllers quedan así de limpios!
    • 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
    • Service Tags (II)• El componente Translator lo usa para los loaders• O cuando necesitamos crear un Event Listener
    • 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
    • Agradecimientos• A los Ulaboxers PHPeros: Sergi, Albert, Marc• Al equipo #rigor de @EmagisterTech• A la organización y sponsors de DeSymfony• A todos vosotros :)
    • ¿Preguntas?• E-mail: ricard.clau@gmail.com• Twitter: @ricardclau• Github: https://github.com/ricardclau• O si os da corte ahora... en otro momento :)