Por qué desarrollar tu proyecto con Symfony

A la hora de desarrollar un proyecto es muy común preguntarse qué tecnología utilizar así como el hecho de utilizar un CMS (Content Management System) o un plataforma de e-commerce. Ambos se han hecho muy populares en los últimos años debido a que contienen una serie de funcionalidades estándar que luego se pueden adaptar a cada sitio web que se vaya a desarrollar. Como definición, un CMS es un gestor de contenidos, una aplicación ya desarrollada, que está lista para utilizarse y que permite cierto nivel de personalización y modificación.

Por ejemplo, encontramos como principales CMS para desarrollar una web a Worpdress, Joomla o Drupal y como principales sistemas para crear un e-commerce a Prestashop, Magento o WooCommerce. Cuando el proyecto es de un tamaño pequeño-mediano son plataformas ideales, ya que permiten desarrollar el sitio web de una forma muy rápida, ya que viene ya montado prácticamente todo lo necesario para empezar. Un panel de administración, un editor de texto enriquecido, un gestor de imágenes y hasta un gestor de productos, pedidos e incluso CRM dentro de las plataformas e-commerce. En ocasiones, incluso para proyectos más grandes un CMS puede hacer un gran papel.

No obstante, cuando lo que se quiere desarrollar es algo más potente, que sea muy escalable y a medida pero sin tener que reinventar la rueda, la opción adecuada suele ser la utilización de un framework.

¿Qué es un framework?

Un framework es un conjunto de herramientas y librerías ya desarrolladas y estudiadas que permiten realizar las tareas más comunes dentro del proyecto. Es decir, un framework incluye todas aquellas funcionalidades que suelen tener la mayoría de proyectos ya desarrolladas para que no se tengan que desarrollar de nuevo para cada proyecto. Con esto, el desarrollador gana mucho tiempo, pues mucha parte del desarrollo viene ya preparado. Sin embargo, no hay que confundirlo con los CMS, ya que el framework contiene las funcionalidades, aunque es el desarrollador el que tiene que darle la forma deseada y aplicar y utilizar lo que necesite, de forma totalmente a medida.

Los frameworks, en muchos casos llegan a ser incluso una forma de trabajar y de estructurar el código, esto es, una jerarquía y organización para el proyecto ya predefinida. Algunos de los frameworks para PHP más conocidos son Symfony, Zend Framework, Laravel, CakePHP o CodeIgniter.

¿Por qué Symfony?

Symfony es uno de los frameworks más populares y tiene mucho recorrido, lo cual permite que haya una comunidad importante de desarrolladores. Esto facilita el hecho de que cuando hay que realizar un desarrollo con symfony haya mucha documentación y mucha gente a la que poder preguntarle y compartir.

Este framework funciona sobre PHP y permite con su gran potencia algunas de las siguientes cuestiones:

  • Tener un proyecto bien estructurado y donde pueden trabajar / aportar muchos desarrolladores a la vez. Es decir, el hecho de trabajar con Symfony hace que una vez que una persona ha aprendido symfony luego pueda trabajar en un proyecto nuevo de forma sencilla, ya que conoce perfectamente la estructura y dónde encontrar cada funcionalidad. Incluso y por el mismo motivo, permite que un desarrollador pueda ayudar en un proyecto que ya está en desarrollo.
  • Tener un orden en el proyecto. Es fundamental, ya que cada desarrollador podría trabajar de una forma, y al utilizar un framework todos siguen un mismo orden.
  • Escalabilidad. Trabajar de una forma tan estructurada pero a la vez pudiendo desarrollar a medida, permite una gran escalabilidad. Es una de las principales diferencias a la hora de crear un proyecto con un CMS o con un framework, con este último generalmente se puede crecer todo lo necesario sin necesidad de estar cambiando constantemente todo el motor de la web.
  • No reinventar la rueda. En symfony como en el resto de frameworks es lo que se pretende. No tener que desarrollar cada vez un login de usuarios o un buscador, sino utilizar los que ya vienen, que además son mejorados constantemente por la comunidad, lo que permite tener siempre unas funcionalidades potentes y actualizadas con un esfuerzo menor. Si cada vez se tuviera que desarrollar cada funcionalidad supondría mucho tiempo y dinero, y seguramente el resultado no sería tan bueno.
  • MVC (Modelo-Vista-Controlador). Una forma de trabajar que facilita la vida a los desarrolladores y permite diferenciar entre la parte más de programación y aquella que es más de maquetación, de forma que un equipo de desarrolladores puedan trabajar mejor según su perfil y sin interferir en el trabajo de los demás.
  • Es software libre. El código de symfony es libre y está abierto a todo el mundo. Cualquiera pueda utilizarlo para su proyecto, del mismo modo que puede utilizar PHP. Esto es un gran punto a favor, ya que es algo abierto, en continuo desarrollo y avance y hace que una persona con conocimientos pueda utilizarlo a su servicio e incluso ayudar a los demás desarrolladores a mejorar.

¿Cuándo escoger Symfony?

Se ha hablado de CMS y de frameworks, pero es importante saber cuando elegir cada uno. Elegiremos el framework Symfony generalmente en los siguientes casos:

  • Cuando se necesita flexibilidad. Si en un proyecto se necesita hacer las cosas de una determinada manera y no de otra. Al contrario que los CMS donde las modificaciones están más limitadas en Symfony la programación se puede adaptar de forma total a las necesidades o requisitos del proyecto.
  • Cuando los CMS se quedan cortos. En muchos casos la utilización de un CMS puede limitar las posibilidades del proyecto, por la forma en la que están desarrollados. En symfony se puede complicar el proyecto todo lo deseado, pues permite crecer mucho más.
  • Seguridad. Utilizar symfony frente a un CMS es también un punto a favor de la seguridad, pues la mayoría de los CMS siguen los mismos patrones, mismas URLs para hacer un login y mismos bugs. Esto facilita que cuando hay un error, ese error forme parte de todos los CMS del mercado y haya que estar rápidamente con actualizaciones. En symfony, en cambio, al estar todo desarrollado a medida sobre una base, es más complicado que se puedan difundir este tipo de errores, que serían más concretos para cada proyecto y no tan genéricos.
  • Mejor gestión de recursos. Aunque los frameworks suelen necesitar bastantes recursos, es posible «jugar» con ello, al contrario de lo que ocurre con los CMS, donde la propia estructura de los mismos hace en ocasiones que no se puedan optimizar de todo.
  • Utilización de plantillas y layouts. Pese a que symfony tiene una curva de aprendizaje mayor a la de los CMS, tiene un sistema de plantillas y layouts que permiten que diseñadores o maquetadores HTML puedan aportar al proyecto sin tener demasiada idea del mismo.

 

Agencia desarrollo Symfony

Por todos estos motivos es importante plantearse antes de desarrollar un proyecto qué es lo que más conviene y en el caso de optar por un framework como symfony, rodearse de un equipo de profesionales para poder llevar el proyecto a cabo. Es indispensable trabajar con un desarrollador o agencia de desarrollo Symfony para conseguir desarrollar un sitio web más ambicioso o una aplicación web.

En resumen, se utilizará un CMS cuando sea un sitio web más o menos sencillo o se pueda cubrir de forma rápida por las funcionalidades con las que estos cuentan. Como por ejemplo una web o una tienda online al uso. Y se utilizará el framework symfony cuando desarrollo sea más complejo o se necesite un sitio web más potente y escalable.

Buenas prácticas y consejos para mejorar tu código en Symfony

Symfony es un framework PHP que recientemente ha cumplido los 500 Millones de descargas y es conocido por su gran ecosistema de componentes. También es la base de proyectos como drupal, magento y prestashop(en sus fases iniciales al port hacia symfony) entre otros. Cuenta con una comunidad muy activa, y su creador está entre los miembros del PHP-FIG, es por ello que desde acceseo os queremos mostrar en este articulo una serie de buenas prácticas y consejos para mejorar vuestro código en Symfony.

Una de las principales características, conjuntamente con el sistema de componentes, es la calidad de su documentación, así como un amplio repertorio de test que le proporcionan una gran aceptación por parte de la comunidad y una base muy sólida para empezar cualquier proyecto sin importar su magnitud.

Vamos a citar en primer lugar algunos tips and tricks, y acto seguido, algunas buenas prácticas, extraídas directamente desde la propia sección.

Trucos y consejos para optimizar Symfony

Existen multitud de plataformas que hacen uso de las variables de entorno para almacenar los credenciales de las aplicaciones. Recientemente, symfony (en su versión 3.3) ha publicado un componente llamado Dotenv, el cual nos permite parsear archivos .env. En nuestra aplicación, podemos añadir las variables como parámetros:

// app/AppKernel.php

public function registerContainerConfiguration(LoaderInterface $loader)
{
    $loader->load($this->getRootDir().'/config/config_'.$this->getEnvironment().'.yml');

    try {
        (new Dotenv\Dotenv(__DIR__.'/../'))->load();
        $envParameters = $this->getEnvParameters();
        $loader->load(function($container) use($envParameters) {
            $container->getParameterBag()->add($envParameters);
        });
    } catch (Dotenv\Exception\InvalidPathException $e) {
        // don't do much at the moment, possibly the env variables are set differently (e.g. AWS)
    }

En su versión 3.2 de symfony, se integró el uso de la función env, encargada de obtener el valor de la variable de entorno desde la configuración en yaml con el siguiente formato:

# app/config/config.yml
doctrine:
    dbal:
    # ...
        password: "%env(DB_PASSWORD)%"

En la versión 2.6 fue añadido LockHandler, y en su versión mas reciente, la 3.3, han anunciado el componente llamado Lock component, el cual nos permite bloquear el acceso a los recursos a través de diversos métodos, tales como flock de php, PHP Semaphore extension, Redis y Memcache.

Yaml, human friendly data serialization standard, mantenido por Clark C. Evans, es un standard que tiene por objetivo la serialización de la información de forma descriptiva. En los últimos años ha ganado popularidad, debido a la facilidad de parseado frente a alternativas como XML. Herramientas como Docker, también lo usan para expresar sus archivos de configuración. Symfony cuenta con un componente llamado YAML Parser. Desde la versión 3.3, ahora se nos permite crear etiquetas personalizadas.

$yaml = "!my_tag { foo: bar }";
$config = Yaml::parse($yaml, Yaml::PARSE_CUSTOM_TAGS);

$tag = $config->getTag(); // $tag = 'my_tag'
$value = $config->getValue(); // $value = array('foo' => 'bar')

Lo podemos usar para añadir funcionalidades específicas para la configuración de nuestro bundle, por ejemplo.

Como última novedad, han incorporado la carga de archivos locales con patrones globales. Ahora podemos hacer lo siguiente:

const CONFIG_EXTS = '.{php,xml,yaml,yml}';

// ...
protected function configureContainer(ContainerBuilder $container, LoaderInterface $loader)
{
    $confDir = dirname($this->getRootDir()).'/etc';
    $loader->import($confDir.'/packages/*'.self::CONFIG_EXTS, 'glob');
    $loader->import($confDir.'/packages/'.$this->getEnvironment().'/**/*'.self::CONFIG_EXTS, 'glob');
    $loader->import($confDir.'/container'.self::CONFIG_EXTS, 'glob');
}

Existe una característica del componente Config no muy conocida, que nos permite hacer override de los archivos que hemos cargado:

# app/config/config.yml
imports:
    - { resource: 'parameters.yml' }
    - { resource: '/etc/sites/mysite.com/parameters.yml', ignore_errors: true }

De esta forma, podemos tener en el servidor de producción un archivo con los parámetros correspondientes. Sin embargo, en local, como no existe dicho archivo y le hemos indicado que no lance excepción seguirá el flujo habitual de la aplicación.

Por lo que a conexión con capa de persistencia de datos se refiere, symfony usa Doctrine, un ORM (Object Relational Mapper). Los bundles con los que viene symfony, por regla general, vienen con una gran cantidad de configuración por defecto que nosotros podemos modificar según nuestras necesidades. Por lo que respecta al naming de las tablas, resulta común que la estrategia varíe según los requisitos del proyecto. Para tal propósito, podemos forzar la estrategia de naming con una configuración, para evitar la redundancia de escribir el parámetro en cada valor de la entidad en caso de pretender modificar el comportamiento habitual:

    #app/config/config.yml
        config:
            doctrine:
                dbal:
                # ...
                orm:
                    # ...
                    entity_managers:
                        default:
                            naming_strategy: doctrine.orm.naming_strategy.underscore

También podremos hacer nuestras propias estrategias de naming haciendo uso de la clase: Doctrine\ORM\Mapping\NamingStrategy según indican en su documentación.

En lo referente a su motor de plantillas, twig, hay interesantes mejoras que podemos utilizar.

Disponemos de la posibilidad de evaluar si existe un bloque, a través de la siguiente sintaxis:

{%if 'block_name' is block%}
   Esto es un bloque
{% endif %}

Cuando creamos nuestros propios filtros, y necesitamos proporcionarle un número arbitrario de parámetros de entrada, podemos usar la opción is_variadic

$filter = new Twig_Filter('thumbnail', function ($file, array $options = array()) {
// ...
}, array('is_variadic' => true));

Para finalizar, podemos usar lo que llaman, named arguments. Nos confían una mayor legibilidad en el código:

{{ data|convert_encoding(from='iso-2022-jp', to='UTF-8') }}

En cuanto a los logs, symfony cuenta con su propio componente, que nos ayuda identificar los estados por los cuales pasa nuestra aplicación. Es un gran desconocido,
pero cuenta con muchas funcionalidades que nos pueden ayudar identificar problemáticas futuras.

Podemos crear canales personalizados, de forma muy sencilla:

    # app/config/config.yml
    monolog:
        channels: ['foo', 'bar']

Ahora symfony ya permite pasar el canal de log a través de un argumento:

#app/config/config.yml
services:
    some_service:
        class: Namespace\Some\Service
        arguments: ["@monolog.logger.alert"]

Podemos crear formatters personalizados desde la configuración, sin necesidad de implementar una clase de formateo:

#config.yml
services:
    app.log.formatter:
        class: Monolog\Formatter\LineFormatter
        public: false
        arguments:
            - '%%level_name%% [%%datetime%%] [%%channel%%] %%message%%\n' #mensaje a escribir en el archivo de log
            - 'H:i:s' #formato
            - false #ignorar \n en los logs

Configurando donde queremos usar dicho formato:

#app/config/config.yml
monolog:
    handlers:
        main:
            formatter: app.log.formatter

Gestión de correos en entorno de desarrollo

Cuando se trata de correos, son una parte básica de cualquier aplicación, sobretodo si la aplicación tiene usuarios y deseamos verificar el correo de registro, por ejemplo. En entornos de desarrollo, es importante que los emails, sigan el flujo habitual. Así como la posibilidad de poder visualizarlos. Nosotros lidiamos con este problema con una herramienta llamada Mailhog, el cual cuenta con repositorio en github. Podemos ir a la sección releases de la documentación para encontrar la última versión compilada de la misma. Está dotado con un servidor de stmp y un panel web para visualizar todos los correos salientes de la aplicación. Es una gran opción que no necesita de instalar daemons en el caso de linux, tan sólo ejecución en el momento en que necesitemos de la funcionalidad.

En symfony tenemos una guía para organizar los entornos con diferentes archivos de configuración de manera jerárquica en función de los directorios como se muestra en la documentación. Esto nos puede servir para cargar diferentes configuraciones, como por ejemplo en este caso, que nos interesa cambiar los datos del servidor smtp para poder evaluar la aplicación al completo.

Buenas prácticas en Symfony

Por último vamos a citar algunas de las buenas prácticas a modo de resumen, que nos proporcionan desde la sección de best practices.

Configuración:

  • Define toda la configuración de la infraestructura en el archivo parameters.
  • Define todos los parámetros en parameters.yml.dist. Ten en cuenta que composer evalua este archivo para regenerar el parameters.yml.
  • Define la configuración de la aplicación en config.yml.
  • Usa constantes para definir la configuración.
  • El naming de los parámetros debería ser lo mas corto posible.

Organizar la lógica de negocio:

  • Usa nombres lo mas cortos posibles para los servicios del bundle.
  • Escribe la configuración de los servicios en archivos YAML
  • Como hemos comentado anteriormente, mueve los datos sensibles fuera de la aplicación con variables de entorno.

Controladores:

  • Los controladores deben extender siempre del controlador base de FrameworkBundle.
  • No uses la anotación @Template.
  • Usa ParamConverters para obtener la entidad en el controlador.
  • Por norma general, como indican en la documentación, los controladores deberían seguir la regla 5-10-20. 5 líneas variables o menos, 10 acciones o menos y 20 líneas o menos

Como conclusión final, symfony tiene una curva de aprendizaje en sus inicios algo elevada, pero cuando se domina el framework en sus aspectos más básicos nos puede ayudar con un ágil desarrollo con poco esfuerzo y una gran calidad del código, siguiendo unas normas básicas de buenas prácticas.

¿Tienes alguna incidencia?

Cuéntanos qué ocurre
y nos pondremos con ello lo antes posible.

Este sitio está protegido por reCAPTCHA, y la Política de privacidad y Términos de servicio de Google.
Sucríbete a
nuestra newsletter

para estar al día en el mundo online

¡Cuéntanos tus ideas!
+34 96 653 19 14
+info@acceseo.com
He leído y acepto la política de privacidad

Este sitio está protegido por reCAPTCHA, y la Política de privacidad y Términos de servicio de Google.