En tanta_ nos estamos replanteando con que herramientas  vamos a hacer el desarrollo del software. Nos estamos dando cuenta que estamos haciendo un uso intensivo de los gestores de contenido, que en unos casos nos aportan ventajas, pero que utilizados para todos los proyectos estamos perdiendo las ventajas de poder utilizar frameworks que implementan buenas prácticas en el desarrollo del software, que la mayoría de los CMS que estamos utilizando no nos permiten aprovecharnos de ellas.

En desarrollo web es muy frecuente utilizar un CMS por la facilidad que nos brinda posteriormente el administrador para la creación de contenidos, y muchos de los portales más importantes se basan en los gestores de contenido (CMS). Pero también hay webs que no tienen porque estar basados en un CMS.

Un CMS tiene muchas ventajas porque al estar orientado al desarrollo web tiene ya implementadas muchas de las funcionalidades más comunes de una web, como por ejemplo SEO, Sitemap, etc. Para que podamos implementarlas fácilmente,  lo que nos lleva, sobre todo al principio, a un coste de desarrollo menor porque ya está desarrollado.

Aparte de ventajas los gestores de contenido también tienen desventajas. Ya partimos del código propio del CMS, que tiene una determinada estructura, que debemos de respetar y seguir, si no las seguimos estamos creando un híbrido inmanejable, estaremos desaprovechando las ventajas del CMS. Puede ser porque realmente no debíamos haber utilizado un CMS, o lo desconocemos y no sabemos cómo utilizarlo, y lo que hacemos es saltárnoslo. Luego será muy difícil de mantener, porque los que tengan que mantenerlo primero buscaran la forma estándar de desarrollarlo y no la encontrarán.

El modelo de datos de los gestores de contenido es genérico porque se puede guardar cualquier tipo de contenido, por lo que ya no pueden estar tan optimizado su diseño como si fuera para un desarrollo determinado.

Muchas veces lo que suele pasar es que están preparados para un montón de posibles funcionalidades. Por ejemplo suelen guardar un historial del contenido introducido en el CMS por si en algún momento queremos recuperar contenido anterior. Son funcionalidades bastante potentes pero generalmente no se suelen utilizar, y lo que muchas veces ocurre con esto es que las consultas contra el CMS sean muy pesadas. En la mayoría se puede configurar este historial para quitarlo o dejarlo para un número determinado de versiones, pero muchas veces no se hace por desconocimiento o falta de tiempo, otras veces es que realmente no se quiere guardar el historial pero entonces también puede ser que realmente no necesitamos un CMS.

También tenemos que estar pendientes de hacer el mantenimiento de las actualizaciones por razones de seguridad, como hay sobre una docena de CMS más conocidos pues son más propensos a ataques, propiamente porque son conocidos y pueden intentar explotar sus vulnerabilidades y por el hecho de que pueden atacar más sitios al estar su uso muy extendido.

En un proyecto web en el que vemos que no se van a estar cambiando constantemente los contenidos, no deberíamos de utilizar un CMS, sería mejor utilizar un desarrollo a medida que tiene las siguientes ventajas:

Como es a medida, nosotros podemos elegir con que lo vamos a desarrollar y podemos utilizar una tecnología y un framework que nos venga mejor para lo que vamos a desarrollar.

Suele ser menos pesado y estar más optimizado (siempre que sigamos unos mínimos patrones) porque tenemos menos dependencias y menos “código sucio” generado por el CMS.

Si hacemos un desarrollo a medida tampoco debemos de ir totalmente por libre y debemos seguir unos patrones en el desarrollo, siguiendo buenas prácticas y no intentando reinventar la rueda, por ejemplo ya no se debe de hacer consultas directamente contra la base de datos se debería de utilizar un ORM.

 

Ventajas de utilizar un ORM.

Las bases de datos son relacionales, actualmente todos los lenguajes de programación están orientados a objetos, aunque algunos CMS como por ejemplo WordPress o Drupal todavía están orientados a procedimientos. Para acceder de forma efectiva a la base de datos desde un contexto orientado a objetos, es necesaria una interfaz que traduzca la lógica de los objetos a la lógica relacional y viceversa.

Al utilizar un ORM como es algo estándar ya está implementada por otros la seguridad, y ya nos podemos olvidar de cosas como Sql Inyection, etc.

Si hacemos consultas directamente contra la base de datos dependemos del tipo de base de datos y por eso debemos utilizar un lenguaje que corresponda con la base de datos al escribir las consultas SQL.

Esto es algo importante a considerar ya que cuando se crean elementos de acceso a los datos. Si se cambia a otro sistema gestor de bases de datos, es necesario reescribir parte de las consultas SQL que se definieron para el sistema anterior. Si se crean las consultas mediante una sintaxis independiente de la base de datos y un componente externo se encarga de traducirlas al lenguaje SQL concreto de la base de datos, se puede cambiar fácilmente de una base de datos a otra.

Aparte de que casi ningún CMS de los más conocidos está utilizando un ORM para acceso a los datos, suelen tener una API propia de acceso a datos, con lo que muy probablemente con la mayoría de los gestores de contenido seremos dependientes de la tecnología de la base de datos, y no la podremos cambiar o nos será difícil, ya sea MySql, Oracle o SqlServer con las implicaciones de escalabilidad, dependencias del sistema operativo de la propia tecnología de base de datos, etc.

La utilización de objetos en vez de registros y de clases en vez de tablas, tiene otra ventaja que permite añadir métodos accesores en los objetos que no tienen relación directa con una tabla, por ejemplo tenemos una tabla cliente con los campos nombre y apellidos, para crear una propiedad nombreCompleto es tan fácil como crear una función que nos devuelva el nombre completo cuando realmente no es necesario almacenarlo en la base de datos, también para propiedades de totales, etc.

Actualmente la arquitectura del software está orientada a hacer desarrollos multicapas con el menor nivel de acoplamiento posible porque nos brinda una gran cantidad de ventajas y los frameworks de desarrollo de software actuales nos orientan a seguir unas buenas prácticas entre las que se encuentran el desarrollo de arquitecturas multicapas.

 

Ventajas de arquitectura multicapas con bajo acoplamiento.

La arquitectura multicapa con bajo acoplamiento lo que permite entre otras cosas es tener a varios perfiles trabajando sobre un mismo proyecto y que puedan colaborar y tener menos dependencias unos de otros. Esto se logra en mayor o menor medida cuando estas capas tienen un nivel de acoplamiento bajo entre ellas. Así a mayor acoplamiento más dependencias unas de otras y nos lleva a que no podamos separar claramente por ejemplo las tareas de back de las de front,  lo que nos lleva a no poder dividir el trabajo claramente y tener que hacerlo al mismo tiempo.

Además tendremos problemas de reutilización  si la vista está acoplada al back, no podremos cambiarle el front por otro fácilmente, porque tiene muchas dependencias, y luego nos será muy difícil buscar todas esas dependencias para poder cambiarle a ese back la vista. Al igual pasa con la vista, si esta acoplada al back, será ya muy difícil de utilizarla en otros proyectos porque ya tendrá dependencias de ese back.

También ocurre que a mayor acoplamiento un cambio produce un efecto dómino de cambios en todos los módulos.

También implica que los módulos son más difíciles de probar, por ejemplo si para probarlo necesitamos utilizar el front.

Algunos de los gestores de contenido más populares como WordPress y Drupal no están orientados al desarrollo multicapa, tienen una aparente rapidez del desarrollo porque su comunidad está muy extendida y nos pueden solucionar muchos problemas, pero a la larga en su desarrollo no tendremos las ventajas del desarrollo multicapas con bajo acoplamiento.

En general no es una buena práctica elegir herramientas de software para el desarrollo de un proyecto porque es una tecnología con la que estamos cómodos, hay que elegir las herramientas que mejor se adaptan al proyecto que vamos a desarrollar, es decir no tenemos que ser dependientes de estas tecnologías, hay que utilizarlas las herramientas software como un medio para lo que queremos hacer.