NDepend 3, radiografía tu código aún más fácilmente

Hace casi un año hablaba de la segunda versión de NDepend, una herramienta capaz de ayudaros a mejorar nuestro código, analizando cientos de aspectos, métricas y reglas a nivel de fuentes y ensamblados.

Recientemente se ha publicado la tercera versión de NDepend, que ofrece interesantes novedades respecto a las anteriores, como la integración absoluta con Visual Studio, el soporte para soluciones multi-proyecto, potentes mecanismos de búsqueda, edición múltiple de CQL, o el seguimiento de cambios, además de las tradicionales características del producto.

Los 10 métodos más extensos de ASP.NET MVC 2

Pero sin duda, lo que me ha parecido más espectacular es su magnífica integración con Visual Studio (2005, 2008 y 2010), que permite disfrutar de toda la potencia de análisis de NDepend, y sus facilidades para la navegación desde el mismo entorno de desarrollo.

Para habilitar esta característica es necesario instalar el plugin en el IDE, que se realiza desde el propio entorno visual de NDepend:

Instalar plugin NDepend en Visual Studio

De esta forma, ya no es necesario acudir a la herramienta Visual NDepend para realizar búsquedas, comprobar reglas o navegar a través de la base de código: lo haremos directamente desde VS, utilizando los menús contextuales. Y gracias a ello, podemos disfrutar de las nuevas opciones de navegación, que nos permitirá surcar el código utilizando rutas distintas a las habituales:

Navegar por el código con NDepend

U obtener diagramas de dependencias de componentes, utilizando el botón derecho del ratón:

Dependencias con NDepend 3

Además, como comenta Patrick Smacchia, padre de la criatura, el rendimiento del entorno prácticamente no se resiente, dado que los análisis se ejecutan en segundo plano de forma incremental.

Recordar, por último, que NDepend es una aplicación comercial, pero dispone de una versión limitada gratuita utilizable por universidades, desarrolladores open source e incluso, durante un tiempo determinado, de prueba en proyectos comerciales.

Página del producto: http://www.ndepend.com/
Radiografiado desde: NDepend 3, radiografía tu código aún más fácilmente @ Variable not found
Hey, ¡estoy en twitter!

Habilitar la compilación de vistas en proyectos ASP.NET MVC 2

Hace un año hablábamos por aquí sobre los ajustes que debíamos realizar para compilar las vistas de MVC 1.0 como parte del proceso de construcción del proyecto. De esta forma tendremos las ventajas del chequeo en tiempo de compilación, que bien valen la pena aún a costa de tener que esperar algo más en cada montaje.

MVC 2 también permite habilitar esta característica en Visual Studio de forma muy sencilla. Sólo seguir los pasos descritos a continuación.

En primer lugar, con el botón derecho del ratón sobre el proyecto MVC 2, selecciona la opción “Descargar proyecto”:

Descargar proyecto

A continuación, de nuevo con el botón derecho sobre el proyecto, seleccionamos la opción “Editar NombreProyecto.csproj” (o .vbproj, dependiendo del lenguaje utilizado):

Editar archivo de proyecto

Con estas operaciones hemos conseguido traer al editor de Visual Studio el archivo de definición del proyecto, en el que debemos buscar el siguiente texto que deshabilita expresamente la compilación de vistas:

<PropertyGroup>
...
   <MvcBuildViews>false</MvcBuildViews>
</PropertyGroup>

Y efectivamente, el único cambio a realizar sería sustituir “false” por “true” :-). Salvando el archivo y volviendo a cargar el proyecto, habremos conseguido lo que pretendíamos.

Volver a cargar el proyecto

Publicado en: Variable not found
Hey, ¡estoy en twitter!

Personalizar las plantillas por defecto de controladores y vistas MVC

imageUna interesante característica de ASP.NET MVC, o más concretamente del conjunto de herramientas incluidas en Visual Studio para darle soporte, es la posibilidad de personalizar las plantillas que el IDE utiliza a la hora de agregar controladores y vistas a un proyecto.

Por ejemplo, cuando añadimos un controlador a nuestro proyecto, el entorno genera por defecto un código como el mostrado a continuación:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
 
namespace MiProyecto.Controllers
{
   public class ProductsController : Controller
   {
      //
      // GET: /Products/
 
      public ActionResult Index()
      {
         return View();
      }
 
   }
}
Pero, ¿qué ocurre si todos nuestros controladores heredan de un controlador base? ¿O si solemos incluir un código de inicialización o métodos comunes? ¿Y si disponemos de un código estandarizado para los métodos Create(), Edit(), etc? ¿O simplemente queremos cambiar el nombre de los métodos propuestos? En todos los casos la respuesta es simple: tendríamos que retocar a mano cada uno de los controladores para adaptarlos a nuestras necesidades.

imageY lo mismo ocurre, aunque de forma aún más frecuente, con las vistas. Al añadir un elemento de este tipo al proyecto es posible seleccionar la plantilla a utilizar, que determinará el contenido generado automáticamente por Visual Studio en función de si se trata de una vista parcial o completa, si será fuertemente tipada y otros aspectos.

Las plantillas disponibles para las vistas aparecen en el desplegable “View Content” del cuadro de diálogo de creación, como se aprecia en la captura de pantalla adjunta.

El contenido generado en cada caso pocas veces resulta válido directamente y requiere bastantes retoques, que debemos repetir una y otra vez en todas las vistas que generemos. Incluso en bastantes ocasiones optaremos por seleccionar la plantilla en blanco (“empty” en el desplegable) para introducir nuestro propio código.

Afortunadamente, podemos personalizar muy fácilmente las plantillas a utilizar en ambos casos:

  • de forma global, es decir, a nivel de entorno de desarrollo en el equipo, por lo que las modificaciones que introduzcamos estarán disponibles para todos los proyectos MVC que utilicemos.
  • de forma local al proyecto, siendo utilizadas únicamente al crear elementos dentro del mismo.

Personalización a nivel de equipo

Las plantillas que utiliza Visual Studio para generar tanto los controladores como las vistas están almacenadas en la carpeta Common7IDEItemTemplatesCSharpWebMVC 2CodeTemplates, dentro del directorio de instalación del IDE.

Por ejemplo, en mi Visual Studio 2010 las podemos encontrar en C:Archivos de programaMicrosoft Visual Studio 10.0Common7IDEItemTemplatesCSharpWebMVC 2CodeTemplatesAddController. En VS2008 es la misma, salvo por la versión del entorno, la 9.0.

En el interior de dicho directorio hay dos carpetas, llamadas “AddController” y “AddView” en las que encontraremos las plantillas T4 que generan el código por defecto para controladores y vistas, respectivamente.

En el caso del controlador, el archivo AddController/Controller.tt contiene la lógica de generación del código, a la que podemos acceder abriendo el archivo con un editor de texto plano, o con el propio Visual Studio, y realizar los cambios que estimemos oportunos (¡previo backup del archivo original, claro!).

Aunque T4 puede llegar a ser complejo, en la plantilla de controladores el código resulta bastante fácil de leer, comprender y modificar.

Para las vistas, si accedemos a la carpeta AddView, observaremos que existe una plantilla T4 para cada una de las posibilidades de contenido disponibles en el desplegable del formulario de diálogo de creación de este tipo de elementos:
Plantillas de creación de vistas
Esto ya nos sugiere dos posibilidades a la hora de personalizar los contenidos de las vistas:

  • la primera, sustituir el contenido de las plantillas incluidas por defecto, como “Create”, o “Details”, de la misma forma que hemos hecho anteriormente con los controladores,
  • o bien, crear nuestras propias plantillas. De hecho, cualquier archivo .tt añadido a esta carpeta hará que en el desplegable aparezca un nuevo elemento:

png
imageEl código de las plantillas por defecto para las vistas es más complejo que el de los controladores, pero aun sin conocimientos de T4 pueden ser adaptados con relativa facilidad.

Personalización a nivel de proyecto

Una vez comprendido lo anterior, la personalización a nivel exclusivamente de proyecto es trivial, gracias a un interesante detalle: Visual Studio, a la hora de generar el código de controladores y vistas acude en primer lugar la carpeta ~/CodeTemplates del proyecto, y busca unas subcarpetas llamadas AddController y AddView, desde donde según el caso, tomará las plantillas.

En el caso de la creación de controladores, si existe  ~/CodeTemplates/AddController/Controller.tt, se utilizará como plantilla en lugar de la definida a nivel de equipo.

Para las vistas, Visual Studio poblará el desplegable de plantillas de contenido a partir de los archivos .tt disponibles en la carpeta ~/CodeTemplates/AddView, sumados a los existentes en la carpeta de la aplicación. En caso de coincidencia de nombre (por ejemplo, si creamos aquí una nueva plantilla “Create.tt”) se tomará siempre la plantilla definida en el proyecto.

Eso sí, para que el compilador no genere errores al ejecutar las plantillas a deshora, es necesario retocar sus propiedades, eliminando la herramienta personalizada y dejando esta propiedad en blanco.

image

Publicado en: Variable not found.

El filtro ChildActionOnly en MVC 2

ASP.NET MVC 2El framework ASP.NET MVC 2 ha introducido un nuevo filtro llamado ChildActionOnly que, como su nombre indica, impide la ejecución del método de acción sobre el que se aplica, a menos que se trate de una “acción hija”.

Supongamos el siguiente código en el controlador, digamos, HomeController:

[ChildActionOnly]
public ActionResult Menu()
{
   Menu mnu = getMenuForThisUser();
   return PartialView(mnu);
}

imageAtendiendo a la ruta por defecto, una petición del tipo GET /Home/Menu generará una excepción, como la mostrada en la captura de pantalla adjunta.

¿Y qué significa eso en la práctica? Pues básicamente que la acción sólo puede ser invocada desde una vista utilizando los métodos Html.Action() y Html.RenderAction().

Ambos métodos, aunque formaban parte del ensamblado futures desde hace algún tiempo, han sido por fin incluídos en MVC 2, y están destinados a introducir en la vista actual el resultado de la ejecución de una “acción hija”, por ejemplo así:

<div id="mainMenu">
   <%= Html.Action("Menu") %>
</div>

La diferencia entre ambos es que Html.Action retorna un string con el resultado de la ejecución de dicha acción, mientras que Html.RenderAction() escribirá directamente la respuesta sobre el canal de salida (Response).

Publicado en: Variable not found.
Hey, ¡estoy en twitter!

Curso de ASP.NET MVC 2 en CampusMVP

CampusMVPHace un par de días, coincidiendo con el lanzamiento de Visual Studio 2010, se ha presentado oficialmente el curso de desarrollo de sistemas web con ASP.NET MVC 2 en el que he estado trabajando durante los últimos meses, y con el que me estreno como autor y tutor de CampusMVP, lo que supone para mí una auténtica satisfacción.

Ha sido un trabajo duro, no es una tarea sencilla estructurar y desarrollar contenidos de cierto volumen partiendo de cero, pero creo que el resultado ha valido la pena. El temario, salpicado con más de dos horas de vídeos demostrativos, ejemplos, y recursos adicionales, es el siguiente:

  • Introducción a ASP.NET MVC, donde realizamos un primer acercamiento al framework MVC, y sentamos las bases sobre las que continuar el aprendizaje.
  • En la  primera aplicación ASP.NET MVC crearemos nuestra primera aplicación partiendo de las plantillas por defecto de Visual Studio, que nos será de utilidad para comprender la estructura de este tipo de proyectos y el funcionamiento del marco de trabajo.
  • Continuaremos añadiendo funcionalidades a esta aplicación, donde introduciremos nuevas características partiendo desde cero, aprovechando la ocasión para profundizar en la creación de modelos, vistas y controladores.
  • Seguidamente estudiaremos la capa Modelo a fondo, viendo distintas formas de implementar sus componentes.
  • A continuación, nos sumergimos en la capa Controlador, detallando minuciosamente la creación de controladores, las posibilidades que nos ofrecen, y el conjunto de herramientas que nos facilita el framework para ellos, como el sistema de routing, el binding, filtros, o resultados de acciones.
  • También trataremos con gran detalle la creación de la capa Vista, donde describiremos sus tipos, implementación y mecanismos del marco de trabajo que nos facilitan la tarea, como los helpers, plantillas, o validadores, entre otros.
  • En Ajax con ASP.NET MVC realizaremos un recorrido por las distintas alternativas para la introducción de Ajax en nuestros sistemas, y mostraremos la solución a escenarios comunes.
  • También trataremos cómo organizar los proyectos en Áreas, y los cambios que implican en cuanto a la estructura y funcionamiento de las aplicaciones.
  • Y por último, dedicaremos un capítulo a temas adicionales, básicamente para tratar otros aspectos no incluidos en los módulos anteriores, como la realización de pruebas unitarias, internacionalización, o el despliegue de aplicaciones.

La duración estimada total del curso es de 8 semanas y se imparte online a través de la plataforma de formación de CampusMVP, a vuestro propio ritmo y con el horario que más os convenga. Y dado que soy tutor del curso, estaré a vuestra disposición para asistiros resolviendo las dudas o inquietudes que os pudieran surgir durante el proceso formativo.

Si estáis interesados, sólo tenéis que ir a la tienda online de CampusMVP y apuntaros directamente. Tened en cuenta que si trabajáis en España los cursos pueden salirle gratis a la empresa gracias a la formación bonificada.

¡Os espero! 😉

Enlaces:

Crosssssssposssssssteado desde: Curso de ASP.NET MVC 2 en CampusMVP, @ Variable not found.

¿ActionLink te genera direcciones que acaban en Length=N?

ASP.NET MVC Esta es una respuesta rápida a una cuestión de Fred C., que me llega vía formulario de contacto en Variable not found, sobre un problemilla que también sufrí en algunas ocasiones, y he pensado que posiblemente pueda interesarle a alguien más, así que ahí va.

El escenario es el siguiente: tenemos en una vista un código para generar un enlace hacia una acción, como el mostrado a continuación:

<%= Html.ActionLink("Acceso externo",    // Texto del enlace
                    "Editar",            // Acción
                    "Productos",         // Controlador
                    new { id=Model.Id }) // Parámetros
%>
ActionLink() generan
Al mostrarse la vista, ya en tiempo de ejecución, nos encontramos con que no se ha generado el enlace que pretendíamos, sino uno como el mostrado en la captura de pantalla adjunta, hacia la dirección/Home/Editar?Length=9.

En primer lugar, utilizando la ruta por defecto, vemos nos está llevando hacia el controlador “Home”, ¿pero no le habíamos dicho que era “Productos”?

Y en segundo lugar, ¿dónde está nuestro parámetro id? ¿De dónde sale ese parámetro Length con el valor 9?

La respuesta a este problema es bien sencilla aunque al principio puede provocarnos algún dolor de cabeza: estamos utilizando una sobrecarga incorrecta del método ActionLink().

Si observamos las distintas sobrecargas de este método, podremos comprobar que sólo una de ellas tiene una signatura compatible con la llamada que estamos utilizando:

public static string ActionLink(
    this HtmlHelper htmlHelper,
    string linkText,
    string actionName,
    object routeValues,
    object htmlAttributes
)
Así, cuando en el código anterior estábamos pasando al método el nombre del controlador, en realidad lo que hacíamos era indicarle los parámetros de la llamada. Eso explica el parámetro Length=9 en la URL: dado que le enviamos un string de 9 caracteres, simplemente se trata de una serialización de sus propiedades.

Y, por tanto, los parámetros de la llamada que estábamos especificando, lo hacíamos como parte de los atributos HTML. De hecho, si analizamos el código fuente de la página generada, encontramos que el parámetro “id” ha sido introducido como un atributo HTML del enlace:

<a href="/Home/Editar?Length=9" id="8">Editar este producto</a>
La forma de solucionarlo es bien fácil, sólo hay que utilizar la sobrecarga apropiada, como:

<%= Html.ActionLink("Editar este producto", 
            "Editar",                     // Acción
            new {                         // Parámetros
            controller="Productos", 
            id=Model.Id 
}
) %> 
 
// O Bien:
 
<%= Html.ActionLink(
             "Editar este producto", 
             "Editar",               // Acción  
             "Productos",            // Controlador
             new { id=Model.Id },    // Parámetros
             null                    // Atributos HTML
) %> 
En fin, que se trata de un pequeño despiste a la hora de codificar, propiciado a veces por la gran cantidad de sobrecargas y la información, algo confusa, ofrecida por Intellisense que nos puede hacer perder unos minutos muy valiosos.

¡Gracias, Fred, por participar en Variable not found!

Post original: ¿ActionLink te genera direcciones que acaban en Length=N?
Por cierto, ¡estoy en Twitter!