Antes de que los marcos MVC se hicieran populares, 1999-2005
Si la aplicación estaba bien codificada, y no era un desastre tipo espagueti, a menudo se usaban los principios MVC, pero de manera implícita e irregular.
- En lugar de usar rutas, cada archivo individual correspondía a una acción del controlador; por ejemplo, /htdocs/user/create.php crearía un usuario, en lugar de enviarlo a un controlador de usuario. En lugar de los parámetros incluidos como parte de la ruta, se usaría la cadena de consulta.
- El código del controlador existiría en la parte superior del archivo, lo que establecería variables para su uso por el código de la plantilla en la parte inferior. Si el programador supiera lo que estaban haciendo, todo el código de plantilla estaría separado del código del controlador y no se mezclaría con él. Si no lo hicieran, todo se mezclaría y, a menudo, vería una línea tras otra de declaraciones de “impresión” que generan HTML mezclado con consultas de la base de datos, lógica de negocios, condicionales que abarcan varias pantallas, incluye ese código de ejecución en lugar de incorporando funciones o clases, y toda otra forma de código imposible de seguir.
- Los parciales y los ayudantes se implementaron como funciones, que se incluyeron en la parte superior de los archivos donde se usaron, o mediante una inclusión principal incluida en cada página, que incluía todas las demás que el sitio podría usar.
- En lugar de usar una implementación de patrones Active Record o Data Mapper, las consultas SQL se usaron directamente en los “controladores” y cargaron datos en variables. A menudo, una clase de modelo o biblioteca o funciones ad-hoc se construía a mano para modelos que tenían una lógica empresarial más complicada que seleccionar, insertar, actualizar o eliminar.
- Todos tendrían sus propias bibliotecas de funciones comunes para hacer cosas como acceder a la base de datos, calcular fechas, procesar formularios, que copiarían y pegarían en cada sitio en el que trabajarían. A menudo esto residiría en algún archivo como funciones. (Php | asp | pl).
Este paradigma todavía está en uso hoy en día y no es una mala elección para muchos sitios que no son aplicaciones, sino que están fuertemente basados en contenido, que son básicamente páginas estáticas con algunas consultas de bases de datos mezcladas y que son editadas principalmente por miembros de equipos no técnicos, donde un marco MVC sería exagerado. Ver: http://www.loudthinking.com/post …
Antes de que PHP y ASP se volvieran populares, 1998 y anteriores
Antes de la invención de PHP o ASP clásico, los sitios serían en su mayoría HTML estático, y todos los scripts vivirían en un solo directorio llamado cgi-bin. Todos estos serían scripts de Perl que utilizaron la interfaz CGI para comunicarse con el servidor web. A veces, una ‘aplicación’ completa existiría en un archivo como un script CGI, como una versión súper primitiva de Sinatra. La gente descargaría scripts de sitios como Matt’s Script Archive, y cada uno sería un proceso independiente lanzado por el servidor web cada vez que se llamara a la URL.
Si no usa PHP o ASP, el sitio usaría una pieza grande y costosa de software empresarial como Vignette StorySever o Interwoven Teamsite que proporcionaría un lenguaje de programación más un control de versiones primitivo.
- TeamSite costó cientos de miles de dólares, si no millones, y básicamente proporcionó una versión primitiva basada en la web de Subversion, con una interfaz empresarial molesta, más un script que generaría páginas estáticas a partir de plantillas, parciales y scripts de Perl. También vendieron un sistema de implementación empresarial que era básicamente una versión primitiva, torpe y basada en Perl de Capistrano o Fabric, nuevamente por cientos de miles de dólares. También había una forma muy amigable para el usuario de hacer formularios para los editores, que requería editar scripts de Perl. No existía la concepción de modelos, vistas y controladores, solo páginas web, archivos de datos planos que se usaban para llenar las páginas web y scripts de Perl que generaban formularios para completar los archivos de datos planos o afectaban la construcción de páginas estáticas. Era realmente un sistema concebido de manera horrible y debieron haber tenido vendedores realmente sorprendentes para venderlo. Tuve la desafortunada experiencia de usar esto con un cliente que lo había estandarizado y todavía lo estaba usando en la década de 2000.
- Hasta donde yo sé, Vignette era algo similar a PHP con un servidor web personalizado, pero con Tcl como lenguaje de scripting, y vendieron muchas ‘aplicaciones de portal empresarial’ que eran básicamente scripts que hacían cosas como mantener perfiles de usuario o publicar contenido, que tenías que personalizar mucho para hacer algo útil.
- Antes de MySQL, descubrir cómo almacenar sus datos era un gran problema. Tendría que licenciar Oracle o SQL Server, o piratear algo con archivos planos. No había una concepción de un ORM (no es necesario, ya que no había objetos modelo para mapear nada).
No había forma de aprender estos sistemas sin comprar capacitación costosa de las compañías, porque no hicieron pública ninguna de sus documentaciones, por lo que tuvo que gastar miles de dólares para incluso aprender a codificar en estos sistemas horribles, o contratar desarrolladores certificados a $ 200 + por hora para comenzar.
Un sitio web que un par de personas en 2011 podría crear durante un hackathon usando Rails o Django podría costar fácilmente millones de dólares en licencias de software y honorarios de consultores en 1998.
