Para los que habéis aplicado MVC en J2EE o en Ruby on Rails os parecerá una aplicación pobre del MVC, pero bueno era lo que teníamos en su momento para ASP.NET, y los que queríamos acercarnos a ese modelo no nos quedaba más remedio que aproximarnos lo más posible a él con las herramientas con las que contábamos.

Ahora, con Visual Studio 2008 la cosa ha cambiado, y tenemos un tipo de proyecto que explota explícitamente el patrón MVC en ASP.NET.

He encontrado un artículo estupendo que habla de ello del cual os dejo el link más abajo, y que además da la puntilla dando unos toques de LINQ.

Por cierto, atención con el modelo de convenciones que utiliza el nuevo MVC para ASP.NET, para los que conozcáis Ruby on Rails os va a resultar ciertamente familiar. Es curioso como las buenas ideas se extienden como la pólvora por las diferentes herramientas de desarrollo.

Os dejo el link:

http://thinkingindotnet.wordpress.com/2007/11/18/aspnet-mvc-framework-primera-parte/

Un saludo.

Miguel.

El otro día, un compañero de trabajo me comentó que estaba a empezar a trabajar con Kumbia (http://www.kumbiaphp.com), un framework de PHP del cual le habían dado buenas referencias.

La curiosidad me hizo entrar en la web y echarle un ojo, y me sorprendió bastante el comprobar que incorpora algunas de las bases de Ruby on Rails, tales como Active Record y el Andamiaje, además de generar automáticamente una estructura de directorios para cada proyecto que creas.

¿Qué quiere decir esto, que las buenas ideas que ha arrojado Ruby on Rails están empezando a asentarse en la comunidad web? Por ahora parece que lenguajes como PHP se hacen eco de estas técnicas, pero, esto va a quedar únicamente para lenguajes de código libre como PHP, y Ruby o lo vamos a poder ver pronto en otros como J2EE y .NET.

Os dejo una URL de un proyecto de ActiveRecord para .NET http://www.castleproject.org/

Saludos.

Miguel.

Uf, ¡qué difícil pregunta! Como siempre una respuesta genérica a esta pregunta es, PUES DEPENDE. Y es que la verdad es cierto, va a depender de muchos factores. No pretendo sacar ningún tipo de conclusión al respecto después de haber terminado este post, pero sí almenos aproximar un poco los factores que bajo mi punto de vista afectan a nuestra decisión.

Antes de nada empezar diciendo que no existe una tecnología absolutamente mejor que las otras, habrá una tecnología que para los factores que rodean tu proyecto será mejor que las otras en un momento dado. Y digo en un momento dado porque ese es el primer problema a la hora de elegir, que contamos con las circunstancias y las previsiones del momento. Las previsiones y las planificaciones, pueden fallar, quedarse cortas o pasarse de largo… y si esto puede ser crítico a la hora de definir un requerimiento funcional imagínate al decidir la plataforma tecnológica sobre la que tu aplicación se va a asentar.

Pero bueno, vayamos al grano y pasemos a hablar un poco de los factores que pueden influenciarnos. Empiezo con los más típicos para luego ir dándole vueltas a otros algo más rebuscados.

Multi-Plataforma

Si tu proyecto tiene entre sus restricciones que sea publicable a través varias plataformas del mercado estás de suerte, almenos a la hora de tachar algunas de las opciones que estés barajando. De todas maneras, un humilde consejo en este aspecto es recapacitar realmente si es realmente necesario que sea multi-plataforma, porque muchos veces lo ponemos de restricción cuando luego al final trabajamos con una y listo. El concepto de multi-plataforma vende mucho, es un cartel muy bueno de marketing, ¿pero realmente lo necesitas?

Sin Coste Económico o de Coste Bajo

¿Puedes pagar licencias? ¿Quieres pagar licencias? Tal vez tengas presupuesto para ello, o tal vez no.

Alta Productividad

Cuidadín con este aspecto, existen plataformas tecnológicas que están directamente orientadas a la productividad, si este es uno de nuestro requerimientos principales, adelante con ellas.

Tamaño del Proyecto

No es lo mismo un proyecto de dos meses que uno de seis que uno de un año. Y aquí no juega sólo lo que tienes pensado hacer ahora, si no la previsión de crecimiento que crees que vas a tener. No es lo mismo estar convencido que vas a desarrollar un componente web que saber que si la cosa va bien vas a tener que empezar a agregar más módulos a la aplicación.

Formación de tus Recursos

Tal vez en tu equipo de trabajo cuentes con personas que tengan experiencia en una plataforma en concreto. Y aprovecho aquí para hacer un inciso: el llevar a cabo una formación de dos, tres semanas en una determinada tecnología para luego acometer un proyecto nada más salir no suele traer buenos resultados (retrasos sobre todo) si no acompañas el grupo de trabajo de algún recurso que ya tenga experiencia contrastada en ella.

IDE

.NET tiene Visual Studio, Java tiene Eclipse/NetBeans/Java Studio Creator, PHP tiene Zend Studio, Ruby on Rails tiene Aptana…

Seguridad

¿Te preocupa especialmente la seguridad? ¿La información que provee o captura tu web debe tratarse de forma especialmente segura?

Servicios Web, Ajax…

Existe plataformas que aportan más facilidades que otras para crear Servicios Web o trabajar con Ajax. Y vuelvo a aprovechar la ocasión para hacer otro inciso, cuidadín con el uso de Ajax, si queréis que vuestra aplicación web funcione como una aplicación de escritorio, no construyáis una aplicación web, construid una de escritorio. Ajax es una herramienta que nos puede ayudar puntualmente para resolver ciertos problemas, pero no se debe abusar, o se volverá contra vosotros.

Integración con el Sistema Gestor de Bases de Datos

Me explico, .NET está especialmente diseñado preparado para trabajar contra SQL Server, Java contra Oracle, PHP contra MySQL… Combinaciones del tipo .NET + Oracle o PHP + SQL Server pueden traeros problemas.

Comunidad, Soporte

Algunas plataformas tienen una empresa detrás que te puede dar soporte ante los problemas que puedan surgir, o una comunidad de usuarios más o menos amplia que te ayude a resolver las dudas.

…

Y aquí me paro, creo que por ahora ya quedan presentes algunos de los factores para echarles un ojo y darles alguna vuelta… pero antes de terminar quisiera comentar cuatro cosas sueltas más a la hora de encarar el desarrollo de una aplicación web.

1) Existen tecnologías satélite a las diversas plataformas del mercado y que son comunes a todas ellas. Estas tecnologías conviene conocerlas, saber cual es su función, para qué las podemos usar y para qué no. Me estoy refiriendo a Javascript, CSS, HTML, XHTML, XML, XSL, JQuery, JSON, AJAX, SOAP, WSDL… No me refiero a empollármelas todas, pero sí saber para qué son cada una de ellas y dónde les puedo sacar partido.

2) Desarrollar una aplicación de escritorio no es lo mismo que desarrollar una aplicación web. La gente que trabaja en web tiene muy fácil pasar a trabajar con aplicaciones de escritorio, cuando la historia es alrevés la penalización es más grande (pero no imposible claro está, estoy hablando de que se necesita algo más de tiempo para ubicarse).

3) Intentad definir un único navegador y una versión del mismo para vuestro proyecto, o seguramente os volváis locos. Si trabajáis con una intranet o algo más cerrado os será viable definirlo así, si tenéis como requisito que vuestra web funcione con varios navegadores del mercado, almenos intentad marcar la versión de cada uno. No es lo mismo desarrollar para un Internet Explorer 6 que para un 7.

Fuf, cada vez me enrollo más en los post, voy a tener que empezar a recortar

Saludos.

Miguel.

Para explicar lo que es el Andamiaje en RoR, nada mejor que utilizar un ejemplo en el cual además os habréis visto miles de veces.

En todas las aplicaciones en las que hayáis trabajado existirán una serie de tablas maestras en base de datos, y como siempre, para tenerlas “al día”, tendréis que haber dedicado su tiempo al mantenimiento de las mismas (vamos, lo de siempre, insertar, editar y borrar). Seguramente muchos de vosotros tendréis el proceso automatizado, por lo que al crear una nueva tabla maestra dispondréis de herramientas que vosotros mismos habréis creado para facilitar dicho mantenimiento.

La historia de todo esto es que Ruby On Rails os provee la posibilidad de automatizar los mantenimientos de tablas maestras de forma automática, sencilla y práctica. Como sabremos ya, RoR es un Framework Web asentado totalmente en MVC, por lo que para mostraros la potencia del andamiaje, se van a utilizar conceptos relacionados con el mismo.

Empezamos con el ejemplo, vamos a crear una tabla maestra que se encargue de almacenar coches, para ello, en lugar de irnos a la base de datos y crearlo desde allí, utilizamos Active Record para hacerlo (ya hemos hablado de Active Record en este blog).

ruby script\generate model Coches

Veremos que RoR ha creado una nueva migración y la ha dejado en /db/migrate/create_coche.rb

La editamos, para que muestra finalmente el siguiente aspecto

class CreateCoches < ActiveRecord::Migration
    def self.up
        create_table “coches” do |t|
            t.column “nombre”, :string
            t.column “fecha_alta”, :datetime
        end
    end

    def self.down
        drop_table “coches”
    end
end

Sí, sí, aunque parezca mentira estáis definiendo vuestra tabla a través de código ruby. Y no sólo es eso, como veréis estáis definiendo como crear la tabla y como echarla “patrás” (contra-medidas). Esto es algo estupendo, vamos, estupendísimo, estáis creado los scripts de base de datos y sus contra-medidas de forma clara y totalmente automatizada, y lista para echarse para atrás en caso de ser necesario.

Bien, después de esto, ejecutamos el script (y todos los que hayamos necesitado crear)

rake migrate

A partir de aquí, magia, si consultamos nuestra base de datos veremos la tabla creada con los campos correspondientes, más un campo sorpresa que RoR genera de forma automática, el campo “id”, el cual crea como clave primaria de la tabla.

Bien, ahora si todo siguiera el curson normal tendríamos que dedicarnos a crear el mantenimiento de la tabla, pero… RoR nos va a volver a ayudar utilizando el Andamiaje. Para utilizar andamiaje lo deberemos hacer en el Controlador, y para ello

ruby script\generate controller Coches

Y añadimos el método “scaffold” al controlador

class CochesController < Application Controller
    scaffold :photo
end

Y voila! Ya tenemos el mantenimiento creado… Podréis verlo levantanto WebRick (el servidor web del propio RoR) entrando en http://localhost:3000/Coches… veréis que podréis editar, actualizar e insertar nuevos coches mola, no?

Eso sí, el interfaz gráfico deja mucho que desear, pero eso es algo que hablaremos más adelante

Saludos!

Resumiendo un poco, Active Record es el patrón de diseño que utiliza RoR para el acceso a datos. La idea es algo que ya muchos conoceréis, aunque no tal vez como Active Record, y que es una forma de acceder a datos abstrayéndonos de SQL y enfocando el esfuerzo en los objetos que nos permiten acceder a cada una de las tablas del modelo de negocio con las que trabajamos.

De lo mejor que he podido ver en el uso de Active Record bajo RoR, es que a partir de los modelos que se van generando a través de los scripts ruby, y la edición de los mismos, son los que van generando las tablas directamente en la base de datos. Además, cada uno de los cambios en el modelo que se van haciendo desde ruby, van generando migraciones de BBDD las cuales puedes en cualquier momento volver atrás, manteniendo la consistencia de la base de datos hacia delante y hacia atrás. La verdad es que es una maravilla de cara a la productividad y a la limpieza del código.

Link en wikipedia http://es.wikipedia.org/wiki/ActiveRecord

Active Record para RoR: http://wiki.rubyonrails.org/rails/pages/ActiveRecord

Proyecto de Active Record para .NET: http://www.castleproject.org/activerecord/index.html

Un saludo!

Miguel.

Título: Ruby On Rails
Autores: Bruce A. Tate y Curt Hibbs
Editorial: Anaya Multimedia (O’Reilly)
ISBN: 978-84-415-2182-7
Idioma: Castellano

Estos 15 días de vacaciones estoy decidido a, por fin, tener un poco de tiempo para empaparme de Ruby On Rails. La verdad es que ya había leido algo anteriormente, pero estos días que he tenido algo más de tiempo la verdad es que lo que he podido ir viendo con algo más de profundidad me ha llamado bastante la atención, así que me fui a la Librería General aquí en Zaragoza en búsca de algo más profundo. Y hubo suerte!

La verdad es que me ha llamado tanto la atención que me da que el gestor de curriculums en lugar de estar hecho con PHP5 + Zend Framework voy a probar con Ruby On Rails. Me apetece bastante más, sobre todo estos días al tener más tiempo y la cabeza mucho más despejada.

Saludos!