En los inicios de Internet, la programación se limitaba a presentar documentos estáticos. Conforme fue evolucionando, surgieron las tecnologías que actualmente conocemos con Lenguajes de Scripting.

En la actualidad, los lenguajes dominantes son PHP y ASP.Net les siguen de manera rezagada Pearl y JSP. Y como tecnologías que están tomando impulso tenemos Ruby (con su framework Rails) y Python (en este punto, creo que la principal razón de que Python esté tomando impulso, es por el uso intensivo que Google le está dando).

Realmente, no interesa en un 100% que tipo de tecnología estemos utilizando. Cada una tiene ventajas y desventajas que nos permite crear nuestros proyectos. En un mundo tan competitivo, no podemos simplemente pensar que utilizando la tecnología del momento, llegaremos a tener mayor éxito.

Las tecnologías cambian y son sustituidas. Nuestros proyectos subsistirán no por el lenguaje o tecnología que utilicemos, sino por la misma esencia del proyecto y como haya sido pensado y desarrollado.

Desarrollo descentralizado

Primero debemos de tener el concepto de programación modular. Sea que estemos desarrollando para una aplicación nativa o para Internet. Pero, centrándonos en el caso de la programación para Internet, al menos deben intervenir 5 tecnologías (SGBD, Scripting, HTML, CSS y JavaScript).

Cuando hablamos de desarrollo descentralizado, en el modelo L5 no nos referimos a estas separaciones (que elementalmente son los cinco nivel del método), nos referimos, en el caso del nivel de Lógica de Programación, a la separación dentro de la lógica, en clases, procedimientos y funciones de una manera correcta.

El desarrollo descentralizado no consiste simplemente en hacer esa separación, de hecho, muchas partes del desarrollo deben estar separadas en componentes, a través de clases bien estructuradas, aprovechando las capacidades del lenguaje que utilizamos. Siempre quiero repetir esto, por que creo que es importante.

No se trata solamente de hacer una aplicación, se trata de que nuestro proyecto llegue a ser un referente en todo sentido. La gran característica de aplicaciones o módulos como Smarty, ADODB, entre otros, es que piensan en la reutilización. Hacer algo que pueda ser aplicado en muchos otros proyectos.

Lo realmente interesante de crear aplicaciones con componentes de este tipo, es que podemos ir creando estructuras personalizables que nos permitan extender su uso; con lo cual, vamos ganando experiencia y nuestro componente se va haciendo cada vez más potente.

Por ejemplo, consideremos un componente del lado de la programación, que nos permita crear backups periódicos de nuestra base de datos. Con una buena combinación de programación e incluso un diseño de interfaz, este módulo nos permitiría agregar una nueva funcionalidad a nuestro proyecto. A la vez que estamos descentralizando funciones, estamos haciendo componentes reutilizables.

¿Por qué sitios como Google o Yahoo pueden ofrecer tan buenos servicios?

Sin duda, es una idea con una gran dimensión de respuestas. Puede que cuenten con los mejores equipos de desarrolladores. Pero parte de su éxito consiste en utilizar una buena técnica de programación que combina componentes descentralizados y reutilizables.

Programando entre tecnologías

Si tomamos como base el caso de Google, podemos conocer que su desarrrollo principal funciona sobre el lenguaje Python, utiliza módulos en otros lenguajes como C para sus funciones. Todos sabemos de la compra que Google hace a otras empresas que utilizan diferentes tecnologías. ¿Cómo es que Google puede controlar todos estos servicios y combinarlos con éxito?.

Los lenguajes por naturaleza, han sido desarrollados para interactuar con componentes desarrollados para si mismos. No permiten la utilización de otro código de manera nativa, sino a través de aplicaciones que son intermediarias entre el lenguaje principal y el huesped.

Además de este tipo de desarrollo, que requiere una configuración más avanzada dentro del mismo servidor, existen otros métodos como los famosos Web Services que permite la comunicación entre dos o más servidores con tecnologías distintas o la utilización de tecnologías estándar como XML, JSON o YAML, cuyos intérpretes han sido desarrollados para muchas plataformas y lenguajes.

PHP + ASP.Net + Ruby

Cómo optimizar y desarrollar más fácilmente utilizando múltiples tecnologías al mismo tiempo. Desde el artículo de introducción, hice mención de que una de las justificaciones para desarrollar bajo el concepto de CROSS-SCRIPTING era que podíamos utilizar lo mejor de cada tecnología para realizar una aplicación basada en Internet.

Debo aclarar que la utilización de varias tecnologías dentro de un proyecto, no debe ser una obligación para desarrollar bajo este método de desarrollo. Si nuestro proyecto no lo requiere, no hay ningún inconveniente en no acatar este punto.

Otra justificación, es que así, vamos independizando los módulos de la aplicación. Cada lenguaje tiene un grado de actualización diferente. También al desarrollar de esta manera podemos simplificar procesos. Por ejemplo, una de las ventajas principales del lenguaje PHP es su versatilidad para manejar variables y que los tipos de datos no son estrictos.

En adición a esto, ASP.Net, está muy integrado con la plataforma .Net de Microsoft, que integra muchas funciones y procedimientos muy potentes. Y si comparamos Ruby, podemos comentar que tiene un gran soporte para la programación orientada a objetos. Y así sucesivamente podemos enumerar muchas ventajas, que al combinarlas, nos permiten integran una aplicación realmente potente.

En la actualidad, es posible integrar todos los servicios en un solo Servidor, generalmente Apache. En los últimos días he leído acerca de la posibilidad de utilizar ASP.Net directamente en Apache. Proyecto como Mono que también permiten programar en ASP.Net bajo otras plataformas como Mac OS X o Linux.

Creo que la mejor manera de integrar cualquier tecnología es haciendo que trabaje bajo el enunciado de un módulo completo, y que se comunique a través de lenguajes estándar. La optimización se hará dentro del mismo entorno de programación.

Comunicación entre la BD y la Tecnología de Scripting: Vistas y Procedimientos

Un ejemplo de comunicación entre dos tecnologías diferentes. Pero, en este caso, resulta más sencillo su comunicación, por la gran diversidad de controladores que existen que permiten comunicarnos de cualquier plataforma de desarrollo de scripting a cualquier Gestor de Base de Datos.

Ahora bien, depende mucho el tipo de comunicación y el grado de privilegios que tenga nuestra aplicación sobre la Base de Datos sobre la que va actuar. Generalmente, tendremos el control total sobre la misma, a excepción de sistemas con una base de datos ya existente, siendo nuestro programa un módulo de extensión. Pero en primer caso, la utilización de consultas directas, no es una buena opción.

El SGBD, recibe instrucciones, generalmente en lenguaje SQL, que luego interpreta y ejecuta. En Base de datos pequeñas o aun en desarrollo, la fracción de segundos de diferencia es casi imperceptible, pero a media que vamos creciendo dentro de la base de datos de registros, la manipulación de esos datos es más lenta. En aplicaciones críticas, ese intervalo puede llegar a ser crucial.

El SGBD optimizará las consultas, pero una mejor manera de hacer que el sistema sea cada vez mejor, es utilizar vistas y procedimientos. Las vistas, son muy parecidas a las consultas comunes de tipo SELECT. Mucho comentan que su existencia, emula a una tabla más dentro de la base de datos.

La principal ventaja es que permite combinar resultados de varias tablas, con lo cual la obtención de los datos es más rápida. Otra ventaja de su utilización, es que en cuanto a los niveles de seguridad, el utilizar una vista es mucho mejor, porque para los usuarios que hacen la consulta, la vista representa una tabla y los campos parecen estar dentro de la misma entidad.

Además, dependiendo del gestor, puede que exista el concepto de Vista de una Vista, en que agrupamos aún más dichos valores, generalmente, por que estamos utilizando varias vistas que utilicen una misma estructura de valores de registros padre comunes.

En cuanto a los procedimientos, son importantes, por que su utilización, también permite un mayor grado de velocidad y seguridad al enviar los valores de los parámetros, permiten ejecutar más de una instrucción o consulta, etc. La comunicación a la base de datos, debe hacerse de igual manera de con cualquier método tradicional.

Posiblemente si así pudiese implementarse, la utilización de un archivo en formato estándar, podría ayudar, para centralizar esas consultas a los procedimientos y vistas, en el formato que más se ajuste (a mi parecer en este punto, XML). 

# XMl 
<?xml version = "1.0" ?>
<database engine = "mysql" version = "5.0">
      <section id =  "views">
            <query id = "90TY67SE">
                  SELECT * FROM `_userslist`
                    WHERE `username` = '%username%'
            </query>
      </section>
</database> 
# PHP 
$user = str_replace('%username%', 'maestrosdelweb',
                              getquery("90TY67SE"));

Generación del Esquema de Modelo XML

Antes de iniciar con la guía, estaba convencido que la mejor tecnología de vinculación para el modelo era XML. He leído arduamente respecto a este tópico, y aunque aun creo que una de las mejores opciones es XML.

El motivo de mi cambio es que aunque XML es muy bueno para describir datos, existen otras tecnologías para describirlos de igual manera, de una mejor manera, siempre adaptada al propósito de lo que se quiera representar.

En la actualidad, tecnologías como JSON o YAML están tomando auge en el área de intercambio de la información. Estos tiene objetivos específicos, pero su mayor ventaja es que describen la información más HUMAN-FRIENDLY, lo cual les proporciona un valor añadido.

Un claro ejemplo de ello se ilustra en el siguiente cuadro: 

# En XML 
<?xml version = "1.0"?>
<article name = "L5">
      <chapter number = "1" title = "Definición del Modelo Multinivel">
            <subtitle>Ventajas</subtitle>
            <subtitle>Desventajas</subtitle>
            <subtitle>Oportunidades</subtitle>
            <subtitle>Retos</subtitle>
      </chapter>
</article> 
# En YAML 
article: L5
chapter:
   - number: 1
   - title: Definición del Modelo Multinivel
  - subtitles: (Ventajas, Desventajas, Oportunidades, Retos)

Lo que si es importante de mencionar es que sea cual sea la tecnología a utilizar, el modelo sugiere que la salida, nunca sea en formato HTML/XHTML y otro propio de las tecnologías utilizadas en los siguientes niveles. Este punto es muy importante y es la base para la implementación del siguiente nivel.
Descargar ejemplo

Lecturas relacionadas