Gerardo Contijoch

Experiencias del día a día trabajando con .NET – ASP.NET, C#, ASP.NET MVC y demas…

Archive for 25 abril 2009

Aprender ASP.NET MVC

Posted by Gerardo Contijoch en abril 25, 2009

Hace poco surgió en la blogósfera, una vez mas, la discusión sobre si ASP.NET MVC es mejor o peor que ASP.NET WebForms y si vale la pena aprender a usarlo. No es la primera vez que hay una discusión de este tipo y no será la última.

Esta vez quisiera aportar mi granito de arena a la discusión y para ello les voy a contar una breve historia personal.

Comencé a trabajar con WebForms hace unos 6 años. Esa fue mi primer experiencia Web, nunca antes había trabajado mas que con HTML puro. Como la mayoría en ese momento (imagino yo), empecé con los tutoriales de Microsoft y con algún Starter Kit. Luego llegó el programa Desarrollador 5 Estrellas de Microsoft, al cual seguí. Y no olvidemos los blogs y sites como Code Project o 4 Guys From Rolla, de los cuales uno puede aprender muchísimo. Sin embargo me resulto muy complicado comenzar a trabajar. Y no era que me faltara dominio del manejo de objetos o falta de habilidades para entender conceptos de programación, ya que en cualquier otro tipo de proyectos no tenía ningún problema. Llegó el punto en que llegué a detestar el desarrollo web. No quería saber nada de la Web, ¡no entendía como había gente que le gustara! Era terriblemente complicado para mi trabajar con conceptos como controles de usuario. Entendía que de alguna manera un objeto ‘TextBox’ terminaba siendo un ‘<input>’ del lado del cliente. Entendía que el ViewState ayudaba a que no se pierdan los valores de los controles. Entendía la diferencia entre procesamiento del lado del cliente y procesamiento del lado del servidor. Sin embargo no entendía como sucedía todo eso y ese era mi problema (y es el de muchos otros). ASP.NET hace un excelente trabajo ocultándole al usuario la verdadera naturaleza de la web y del desarrollo web. ¡No fue hasta un par de años después de comenzar a trabajar con ASP.NET que entendí que era POST y GET! Es increíble, pero sí, hice desarrollo web sin saber lo que era POST y GET (entre muchas otras cosas, por supuesto). Es como conducir un tren sin saber que tiene que ir sobre rieles, el tren va derecho sin que uno haga nada, pero uno no sabe porque es así.

Afortunadamente me topé con el blog de InfinitiesLoop y su famosísimo post Truly Understanding ViewState. Créanme que no estoy exagerando cuando les digo que ese post cambio para siempre mi forma de ver ASP.NET. Fue un click, un instante en que cambió todo. Desde ese momento dejé creer en la magia de ASP.NET y comencé a buscar el porqué y el cómo de todo lo que sucedía en una página. Y fue durante esa búsqueda en la que aprendí que era realmente el desarrollo web. No podía creer todas las ‘mentiras’ (por llamarlas de alguna manera) que había aprendido de ASP.NET. Ojo, ASP.NET no es que sea malo por eso, pero el camino natural de aprendizaje de ASP.NET lo lleva a uno a pensar en terminos de ‘Textboxes’, ‘UpdatePanels’ y propiedades que ‘mágicamente’ persisten en el tiempo en un entorno ‘stateless’ (sin estado) en vez de en posts, forms y requests asincrónicos, que es lo que realmente uno necesita dominar.

¿A qué viene todo esto? Sigan leyendo.

Yo comencé a jugar con ASP.NET MVC desde la Preview 3 (ya hace casi un año) y desde el primer momento me atrapó. No había controles de servidor que me abstraigan de cosas que en realidad no debería abstraerme. No había ViewState, ya no era necesario preocuparme por que guardaba y que no guardaba ahí ni por el tamaño de este. No había más misteriosos scritps que eran inyectados en las páginas sin que lo sepamos. No tenia que preocuparme por decidir si realmente me convenía manejar un evento de un campo de texto en el cliente o del lado del servidor. No existía mas el ciclo de vida de las paginas y sus controles (vean la comparación). Era un enfoque totalmente diferente, en donde el desarrollo web solo se limita a las vistas.

Como podrán notar, tengo preferencia por ASP.NET MVC frente al desarrollo clásico con WebForms, pero eso no significa que no siga trabajando con ellos. Lo sigo haciendo, pero ahora, a diferencia de hace algunos años, se lo que hago, se los pros y los contras de usar o no usar un WebControl, se cuando conviene escribir un HttpHandler en vez de una página y se que consecuencias puede traerme el deshabilitar el ViewState para una página. Ahora tengo más control sobre lo que hago y cómo lo hago porque lo entiendo.

De todos modos prefiero ASP.NET MVC por ser mucho mas sencillo de trabajar. Es más modular (puedo hacer un site entero sin haber escrito una línea de código de lógica de negocios o haber creado las tablas en una base de datos), más fácil de testear (la forma en que esta diseñado lo permiten), es totalmente extensible o personalizable (se puede inyectar código en casi cualquier parte de la cadena de procesamiento de un request), los sites tienden a ser mas livianos (no hay mas ViewState o scripts inyectados por defecto, ni hay que renderizar nada, todo es puro html), etc. Parte de esto se debe a la aplicación del patrón MVC, y parte a la forma en que fue implementado por Microsoft.

¿Porqué aprender ASP.NET MVC?

Rob Connery menciona algunas cuestiones por las que él considera que uno debería aprender ASP.NET MVC y no puedo estar más de acuerdo con él. Sobre todo por la anteúltima: Aprender nuevos conceptos. Usando este framework uno puede aprender nuevos patrones y principios de diseño (Model-View-Controller, Repository, Dependency Injection, Inversion of control, Factory, Template, etc ), mejorar nuestras habilidades con javascript (lo más probable es que querramos darle cierta interactividad a nuestro site, y para eso usamos javascript), conocer nuevas herramientas o librerías (para javascript lo más común es usar jQuery o prototype, para IoC podemos usar un framework como Castle MicroKernel, para el acceso a datos es común ver implementaciones hechas con Linq, NHibernate y Entity Framework), y por sobre todas las cosas, ser mejores desarrolladores y estar mejor preparados para el futuro al conocer las distintas opciones que tenemos para trabajar.

[Update: Aclaro que con WebForms uno también puede aprender patrones, usar javascript, librerías, etc, pero como mencioné anteriormente, el camino natural de aprendizaje con WebForms no hace evidente todas esas cuestiones, mientras que con ASP.NET MVC, sí.]

Con todo esto no quiero decir que ASP.NET MVC les va a solucionar todos los problemas, y que deban abandonar los WebForms, para nada, pero creo que puede llegar a ser un aporte muy interesante en la carrera de un desarrollador web.

Recursos

Hay muchos recursos para aprender ASP.NET MVC, pero la mayoría esta en inglés. Entre los más recomendables se encuentran:

[Update: Se agregaron links a blogs en español sobre ASP.NET MVC.]

De ahora en adelante voy a tratar de postear más contenido relacionado a ASP.NET MVC ya que es un tema que me interesa muchísimo y hay muy poco material en español. Si les interesa y tienen alguna sugerencia o duda sobre el tema, no duden en hacerla.

¡Nos vemos en el próximo post

Publicado originalmente en https://gerardocontijoch.wordpress.com.

Posted in ASP.NET, ASP.NET MVC, Desarrollo Web | 4 Comments »

Ventajas y desventajas del uso de Google como host de librerías javascript

Posted by Gerardo Contijoch en abril 20, 2009

Hoy en día es muy común encontrar sites que dependen de librerías javascript populares como jQuery, prototype o script.aculo.us. Normalmente estos archivos se encuentran almacenados junto al resto de las páginas de un site, lo cual puede traer consecuencias negativas.

Una de las grandes desventajas de hacerlo así es que por cada site que visitemos (y que use alguna de estas librerías), vamos a estar bajando las mismas librerías una y otra vez. Esto se debe a que para nuestros browsers los archivos http://www.misite.com/scripts/jquery.js y http://www.otrosite.com/scripts/jquery.js son archivos diferentes y en realidad lo son, su contenido puede ser el mismo, pero son dos archivos diferentes. Es por ello que si visitamos ambos sites, vamos a estar bajando dos veces el mismo contenido.

Para solucionar este problema (que puede no serlo, en ciertos casos este comportamiento es deseable), podemos recurrir a la ayuda de Google, quien hostea algunas de las librerías javascript más populares. Siguiendo con el ejemplo planteado, para referenciar a la librería de jQuery (versión 1.2.6 en este ejemplo) simplemente tenemos que usar la URL http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js (URL de la versión comprimida de jQuery, podemos quitar el .min para referenciar a la versión estándar, lo cual no sugiero).

De este modo, si www.misite.com y www.otrosite.com usan la misma referencia, nuestro browser va a bajar solo una vez el archivo .js, aumentando la velocidad de carga de los sites (debido a que ya vamos a tener en el caché el archivo bajado).

Y eso no es todo, ya a que si estamos bajando el archivo desde un server diferente al que hostea nuestro site, los browsers modernos pueden bajar las librerías paralelamente a los archivos de nuestro site gracias al multithreading. Si los archivos se encontraran en el mismo server, la cantidad de bajadas simultáneas se vería reducida para evitar la sobrecarga del mismo.

Otro beneficio de usar Google como host es que los archivos que bajemos de ahí, los vamos a estar bajando de servers posiblemente más veloces y en redes con mayor ancho de banda que los nuestros.

Siempre hay un pero

Usar esta técnica tiene sus desventajas también, como lo muestra Derek Allard en este post. La primera de ella es ¿qué sucede si hay un problema con los servidores de Google? Pues simplemente no vamos a tener acceso a las librerías de las cuales depende nuestro site. Derek propone una solución a esto en su post, pero a mi no me funcionó. Imagino que su solución tampoco es válida cuando tenemos plugins u otro tipo de dependencias ya que la carga de las mismas depende de que se haya cargado con anterioridad la librería en cuestión.

Otra de las desventajas es que Google es quien tiene control sobre el código de las librerías, lo que significa que tienen acceso a nuestro código y datos (cuando usamos las librerías, les estamos pasando nuestra información a ellas para que la procesen y las mismas pueden haber sido modificadas para registrar esa información). Si bien no hay que ponerse paranoicos, es un factor a tener en cuenta. También es verdad que muy posiblemente estén guardando información sobre el trafico de nuestro site (contando la cantidad y origen de descargas de los archivos).

Leí en algún comentario de algún blog (el cual no encuentro) que algunos antivirus bloquean la bajada de scripts de otros severs, lo cual tiene sentido desde el punto de vista de la seguridad si uno lo piensa un poco.

Casos especiales

Hay otros casos en los que simplemente nos conviene hostear nosotros mismos esos archivos.

No tiene sentido buscar las librerías en servidores externos durante la etapa de desarrollo, estaríamos haciendo que la carga de las mismas sea más lenta ya que durante el desarrollo de un site, normalmente trabajamos de forma local y siempre va a ser más rápido cargarlas de esa forma.

Otro caso en donde no es viable el uso de esta técnica es cuando el site que usa las librerías es un site interno, es decir, se utiliza en una Intranet y no se publica en internet. Una vez mas, es posiblemente más rápido descargar los scripts desde un servidor en la red local que desde internet.

¡Nos vemos en el próximo post!

Referencias:

Publicado originalmente en https://gerardocontijoch.wordpress.com.

Posted in Desarrollo Web, Javascript | Etiquetado: , , | Leave a Comment »

Crear mocks de clases internas con Rhino Mocks

Posted by Gerardo Contijoch en abril 10, 2009

Hoy descubrí que no se pueden crear mocks de clases con visibilidad internal (o Friend en VB) con Rhino Mocks, lo cual me llamó mucho la atención, mas que nada porque no me había topado nunca antes con ese problema y soy de usar mucho clases internas. El error que se nos presenta cuando intentamos hacerlo es el siguiente:

Castle.DynamicProxy.Generators.GeneratorException: Type is not public, so a proxy cannot be generated. Type: <NOMBRE_TIPO_INTERNAL>

Resulta que cuando creamos mocks, en realidad lo que creamos son proxies a las clases que mockeamos, los cuales interceptan las llamadas a las mismas y simulan el comportamiento que nosotros deseemos. Estos proxies, aparentemente, son generados en tiempo de ejecución en un assembly que se llama DynamicProxyGenAssembly2 (hay que revisar el código de Castle.DynamicProxy.ModuleScope para encontralo), el cual no tiene acceso a los miembros internos del assembly nuestro y es por eso que obtenemos el error que mencioné arriba.

Para solucionar esto, simplemente hay que agregar el atributo InternalsVisibleToAttribute a nuestro assembly y especificar DynamicProxyGenAssembly2 como parámetro.

En realidad no conozco mucho sobre el funcionamiento interno de las clases de Castle.DynamicProxy por lo que no puedo asegurar que el assembly generado dinámicamente siempre va a ser llamado de la misma forma así como tampoco puedo asegurar que los mocks van a funcionar como se espera. Por lo que pude ver no hay problemas y hasta ahora todo el código que escribí basado en esta técnica siempre funcionó como se espera.

¡Nos vemos en el próximo post!

Publicado originalmente en https://gerardocontijoch.wordpress.com.

Posted in Testing | Etiquetado: , | Leave a Comment »

Mis problemas con ASP.NET AJAX

Posted by Gerardo Contijoch en abril 5, 2009

Mi relación con ASP.NET AJAX nunca fue buena. Siempre tuve muchos problemas con la implementación de AJAX de Microsoft. Nunca me gustó usarla, me da la impresión de que es muy pesada y hay que saber demasiado para usarla (los problemas de éste y éste post son un ejemplo de ello). Por cuestiones de trabajo, hace unos meses me vi obligado a usarla y todavía me sigo encontrando con problemas de no muy obvia solución.

Recuerdo cuando usé AJAX por primera vez. Fue con Ajax.NET Professional. Tenia que manejar todo con javascript y no había controles ni nada de eso, el HTML se generaba en el servidor y se enviaba como respuesta al request. Por supuesto que esto no tiene porque ser así necesariamente, se puede generar el HTML en el cliente, pero aún así era mas sencillo de usar. Uno tenia que ensuciarse un poco mas las manos con javascript, pero por lo menos uno tenia control sobre lo que hacía. No me pasa lo mismo con ASP.NET AJAX, no se que es lo que pasa por detrás, no se cuando puede fallar ni donde, el framework inyecta scripts por todos lados… no me termina de convencer. Ojo, no quiero decir que Ajax Pro sea mejor que ASP.NET AJAX, simplemente digo que la solución de Microsoft no me da la seguridad que busco.

Por ejemplo, el caso que mencioné en este post. El error que obtenía era básicamente ‘no se puede cargar el archivo xxxx.js’. Resulta que para cargar un archivo de scripts correctamente (dadas ciertas condiciones, no ocurre siempre) tengo que modificarlo de modo que el mismo notifique que su carga ha finalizado. No es algo muy intuitivo que digamos… Uno puede buscar en muchos lados la respuesta hasta encontrarla.

Otro de los problemas que tengo es el uso de los UpdatePanels. Si no se saben usar, pueden resultar muy peligrosos. Éste post muestra un ejemplo de ello. Creo que una de las características más peligrosas de los UpdatePanels es justamente su facilidad de uso. Da la impresión de que al arrastrar el control a una pagina se nos solucionan muchos problemas, pero podemos estar trayendo muchos mas. Para evitarlo, hay que entender como funcionan y saber como hacerlos funcionar como queremos, pero lamentablemente no es mucha la gente que se toma el trabajo (o tiene tiempo) de leer sobre el funcionamiento interno de los controles y por ello muchas veces son más un problema que una solución.

No se… no me termina de convencer todo esto, supongo que será hasta que me acostumbre…

¿A alguien le sucede lo mismo?

¡Nos vemos en el próximo post!

Publicado originalmente en https://gerardocontijoch.wordpress.com.

Posted in ASP.NET, Desarrollo Web | Etiquetado: , , | 4 Comments »