UML con Visual Studio 2010

Quienes trabajamos en alguna de las ramas de la ingeniería hemos encontrado en las representaciones gráficas un elemento valioso de comunicación y documentación. En nuestro día a día utilizamos modelos gráficos para muchas de nuestras tareas, por ejemplo cuando tenemos que diseñar las tablas de nuestras bases de datos o al momento de armar un diagrama de clases que sera parte de la lógica del sistema. Continuamente “dibujamos” modelos, ya sea escritos en papel o con herramientas informáticas.

Ahora bien, hagamos un poco de historia sobre el modelado gráfico dentro del ciclo del desarrollo de software. A mediados de los 80’s, la elaboración de los modelos se convertía en una tarea cada vez  mas compleja. En parte debido a que los sistemas crecían en su  arquitectura  y que la tecnología continuamente brindaba nuevas posibilidades y capacidades de comunicación, almacenamiento y procesamiento entre otras.

Sumado a todo esto, la  falta de un estándar en la forma de elaborar estos modelos complicaba aún mas las cosas. Imaginemos a aquellas personas ajenas a la elaboración del modelo que debían interpretar, por ejemplo, los diagramas de transición de estados de un proceso crítico de la empresa. Antes tenían que conocer el significado de cada elemento que formaba parte del modelo, y recién después comenzar a analizar la lógica del negocio. Esta claro que si cada uno hacia los cosas a su manera, en algún punto se iban a encontrar con una perdida de esfuerzos importante, por ejemplo, cuando se debían presentar estos modelos a un cliente o cuando un grupo externo de desarrolladores se sumaban al proyecto.

Unified Modeling Language

Unified Modeling Language

Surgió entonces la necesidad de que apareciera un lenguaje que permitiera “trabajar” a todos de la misma forma y bajo las mismas reglas. Este nuevo lenguaje tendría que proporcionar los elementos necesarios a utilizar en las distintas estapas del desarrollo del software (es decir, que no solo estuviese pensado para una etapa en particular del ciclo, sino que abarcara todas las fases).

Con todos estos objetivos en mente apareció el lenguaje UML (Unified Modeling Lenguaje). El mismo se empezó a gestar a mediados de 1994 cuando James Rambaugh se unió a la empresa Rational de Grady Booch. El primer paso en la creación de este nuevo lenguaje fue unificar dos métodos que cada uno había desarrollado: el método Booch (de Grady Booch) y OMT (de James Rambaugh). A fines de 1995 se uniría a Rational el investigador Ivar Jacobson quien aportaría muchas de sus ideas y a partir de ahí surgirían los primeros borradores de UML.

Los Tres amigos: Grady Booch, Jim Rumbaugh and Ivar Jacobson

Los Tres amigos: Grady Booch, Jim Rumbaugh and Ivar Jacobson

Además del aporte de los llamados “Tres amigos” se tomó lo mejor de otros reconocidos autores, como por ejemplo Meyer, Harol y Embley (de aquí la de-nominación de Unificado) y en 1997 se convertiría en un estandar del OMG (Object Management Group).

La unificación agrupa otros enfoques

La unificación agrupa otros enfoques

A principios de 2002 se aprobaría la versión 2.0 de UML y actualmente se encuentra la versión 2.4 fase beta (lanzada en marzo de 2011).

Pero, qué es realmente UML? Es un lenguaje de modelado visual y como todo lenguaje tiene una sintaxis y una semántica bien definida (reglas sobre como debemos elaborar e interpretar los modelos que generamos). Recordemos que un modelo es una simplificación de la realidad y el objetivo del modelado de un sistema es capturar sus partes ecesenciales (realizando una abstracción del dominio del “problema” y plasmandolo de forma gráfica).

UML además nos permite trabajar con diferentes diagramas en diferentes etapas del desarrollo de un sistema. Por ejemplo en la etapa de análisis podríamos utilizar un Diagrama de Caso de Usos, en la de diseño un Diagrama de Clases y en la etapa de implementación el Diagrama de Despliegue.

En este post vamos nos vamos a enfocar en el Diagrama de Clases y las herramientas que nos provee Visual Studio 2010 para trabajar con UML (esta por demás decir que VS nos permite trabajar con distintos diagramas como veremos en un momento). Cabe destacar, que lamentablemente la única versión de Visual Studio 2010 que nos permite trabajar con las mismas es la Ultimate (Professional y anteriores solo nos permiten visualizar los diagramas). Más info sobre esta herramienta en la página oficial.

Ok, arranquemos!… En primer lugar, seleccionamos agregar nuevo proyecto, desde el menú Archivo o desde el acceso directo que nos brinda la aplicación en la sección de bienvenida. Una de las nuevas plantillas de proyectos que tenemos en esta versión de VS 2010 con respecto a la otras es la de poder crear Proyectos de modelado.

Proyecto de Modelado

Proyecto de Modelado

Agregando este proyecto tendremos la posibilidad de crear cualquiera de los diagramas que se ven en la siguiente imagen:

Agregando un nuevo diagrama

Agregando un nuevo diagrama

Específicamente, en este post vamos a explicar como trabajar con un Diagrama de Clases UML pero sería bueno conocer los diversos diagramas que nos brinda Microsoft Visual Studio 2010 Ultimate en caso de que los necesitemos algún día.

Una vez que creamos el diagrama de clases en la pestaña de herramientas vemos los diferentes elementos de los cuales podemos utilizar para llevar a cabo el modelo que necesitamos (Class, Interface, Enumaration, Comment, Association, Aggregation, Inheritance, entre otros).

Herramientas del diagrama

Herramientas del diagrama

Para quienes no conocen o no trabajaron con UML las clases se representan de la siguiente manera:

UML - Representación de una clase

UML - Representación de una clase

Por atributos entendemos a las características del elemento en cuestión que debemos incluír en el modelo. Por ejemplo, el nombre y el número de documento podrían ser atributos dentro de una entidad Persona.

Las operaciones serían aquellas acciones o aquel comportamiento propio del elemento (o clase) que permiten que se relacione con su entorno. Siguiendo el ejemplo, la acción comer podría ser una operación de Persona.

Por último, las responsabilidades son aclaraciones que nosotros mismos podemos incluir dentro del modelo para no olvidar particularidades propias de los elementos a modelar.

Para agregar una clase, disponemos dentro del toolbox  del elemento Class . En este elemento podemos describir atributos y operaciones, de acuerdo a lo que hayamos percibido en nuestra interpretación del sistema a modelar. En VS la representación gráfica se corresponde a lo expresado en UML: nombre de la clase alineado en la parte superior y dos recuadros por debajo, uno para indicar los Atributos y otro para indicar las Operaciones (podemos incluir las responsabilidades con el objeto Comment).

Para insertar un nuevo Atributo, debemos hacer click derecho sobre el elemento del tipo Class agregado y luego en Agregar->Attribute. Mas adelante, explicaremos como editar los atributos mediante la interfaz de VS de una manera rápida. Insertar una Operación es un proceso similiar, a diferencia de que debemos hacer clic en la opción Agregar->Operation. Las opciones que podemos modificar en la misma son las que se muestan en la siguiente imagen:

Propiedades de un atributo

Propiedades de un atributo

En cuestión de segundos podemos agregar una Operación y configurar su firma, los parámetros que recibe y la visibilidad (+ Public, Private, # Internal o ~ Package), entre otras opciones.

También podemos indicar como se relacionan nuestras clases entre si, haciendo uso de los elementos:

Association: relación entre una clase origen y otra clase destino. No es una relación fuerte ya que la vida de un objeto no depende del otro.

Relación de Asociación

Relación de Asociación

Aggregation: la clase origen hace referencia a objetos de la clase destino. El tiempo de vida de un objeto no depende del que lo contiene.

Relación de Agregación

Relación de Agregación

Composition: la clase de origen hace tiene objetos de la clase destino. A diferencia de la Aggregation, en este caso el tiempo de vida del elemento contenedor condiciona al tiempo de vida del elemento contenido.

Relación de Composición

Relación de Composición

Dependency: una clase depende de otra.

Relación de Dependencia

Relación de Dependencia

Inheritance: una clase “hereda” de otra, es decir, recibe su comportamiento, atributos y responsabilidades. En UML veremos que esto se denomina con el nombre de Generalización, pero en el ambiente de la programación esto es mas conocido como herencia.

Relación de Generalización

Relación de Generalización

Para agregar cualquiera de estos elementos debemos seleccionarlo desde el cuadro de herramientas. Primero hacemos click sobre la clase origen, y luego sobre la clase destino para indicar la relación. En la siguiente imagen podemos ver un ejemplo rápido de un diagrama de clases creado utilizando estas herramientas:

Diagrama de Clases

Diagrama de Clases

Cada elemento que incluimos en nuestro modelo tiene una gran cantidad de propiedades que podemos editar para hacer nuestro diagrama tan complejo como queramos. Por ejemplo, veamos las propiedades que nos permite editar sobre la clase Tarjeta:

Propiedades de Clase

Propiedades de Clase

Hemos visto las herramientas que nos provee Visual Studio 2010 que nos permite utilizar UML de una manera sencilla y eficiente.

Espero que les sea de utilidad!

Gracias a @mferrero por colaborar en el articulo!

Anuncios

Windows 8 – Creando nuestra primer aplicación Metro

Como ya sabran, hace unos meses se realizo el evento Build Windows en el cual se presentaron las versiones Preview de algunos productos de Microsoft, entre las cuales se encuentran Windows 8, Visual Studio 11 Express, Expression Blend 5, IE10… además de muchas otras novedades.

Build Windows

Build Windows

De Windows 8 una de las cosas que mas me llamo la atención respecto de su versión anterior Windows 7  fue la interfaz de usuario denominada Metro, la cual tiene cierta similitud a la de Windows Phone y esta orientada principalmente a los dispositivos “touch“.

Interfaz Metro de Windows 8

Interfaz Metro de Windows 8

Como podemos observar en la imagen de arriba, los accesos a las aplicaciones están organizadas en una especia de cuadricula, y cada una de ellla esta representada por algo similar a los “Live Tiles” de  Windows Phone 7  (son los “rectángulos” que ademas de hacer la función de “icono” de una app, pueden contener tener cierta funcionalidad extra, como por ejemplo mostrar información o notificaciones de forma dinámica sin necesidad de acceder a la misma). Esta de mas decir que los cambios respecto al tradicional escritorio (que veremos mas adelante no desapareció) son significativos.

La idea de este post es mostrarles los pasos que deben seguir para crear una app Metro utilizando Visual Studio 2011 Express y finalmente poder correrla en Windows 8.

Lo primero que vamos hacer es descargar e instalar Windows 8 Developer Preview desde aquí. Les recomiendo que descarguen la ISO Windows 8 Developer Preview with developer tools English, 64-bit (x64) que viene con el kit de desarrollo integrado. Respecto de la instalación, solo decirles que es similar a la de Windows 7.

Una vez que terminemos de instalar el SO e iniciemos sesión (podemos utilizar nuestra cuenta de Windows Live), lo siguiente que vamos a hacer será ejecutar Visual Studio 11 Express for WDP (el acceso lo podrán encontrar a la derecha de la pantalla de inicio).

Iniciando Visual Studio 2011 Express

Iniciando Visual Studio 2011 Express

Como verán, el clásico escritorio no desapareció (aunque tiene algunos cambios) y VS2011 sigue manteniendo el aspecto de VS2010, pero con varias mejoras, algunas de ellas las iremos nombrando a lo largo del post.

Continuemos, es el turno de crear una nueva aplicación Windows Metro Style con Javascript  – …sí, leyeron bien, una app de “escritorio” con Javascript – . En el menú seleccionamos “File/New/Project…” y dentro de los templates disponibles vamos a seleccionar “Javascript/Split Navigation” (dicho template esta pensado para crear aplicaciones del estilo lector de feeds muy simples y que podemos organizar en categorías):

Seleccionando el template del proyecto

Seleccionando el template del proyecto

Tal como comentaba antes, desde ahora vamos a poder crear aplicaciones de escritorio utilizando HTML5 , CSS y Javascript, una excelente noticia para quienes desarrollamos aplicaciones web! 🙂 (no obstante, tenemos la posibilidad de crear aplicaciones en C# o VB utilizando XAML para definir la interfaz).

Si inspeccionamos un poco el proyecto, vamos a ver elementos mas que conocidos: una carpeta con archivos CSS en donde tendremos nuestras hojas de estilos, documentos HTML 5 en donde construiremos la interfaz de nuestras apps y los script de Javascript que tendrán toda la lógica de las mismas.

Estructura del proyecto

Estructura del proyecto

Dentro de la carpeta winjs están las librerías Javascript que la gente de Microsoft ha creado especialmente para este tipo de aplicaciones. Esta nuevas libs nos proveen de un conjunto de archivos (CSS y JS) que nos permitirá construir y personalizar aplicaciones Metro de una manera sencilla.

Un ejemplo bien simple del uso de esta librería es la siguiente instrucción que nos permite iniciar la app:

WinJS.Application.start();

También podemos definir el comportamiento de eventos, como en el siguiente ejemplo:

WinJS.Application.onmainwindowactivated = function (e) {
    ...
}

Luego de crear la app lo que hice fue meter un poco de mano en el código y modificar la lógica existente para que podamos leer las entradas del blog (inicialmente solo utiliza datos estáticos que genera por código). No voy a entrar en detalles acerca del código en este caso, pero he utilizado entre otras cosas algunas funciones de la nueva librería WinJS, como por ejemplo la función WinJS.xhr que me permitió hacer un XMLHttpRequest (xhr) a los feeds del blog.

Otro punto a favor (aunque no una novedad), es la integración con Expression Blen 5 Developer Preview, el cual utilice para modificar algunos aspectos de diseño – sigo teniendo bien en el fondo espíritu de diseñador – :

Modificando la interfaz con Expression Blend

Modificando la interfaz con Expression Blend

Algunas de las mejoras de VS2011 que fui encontrando mientras “trabajaba” en la aplicación, fueron el Intellisense para Javascript, el editor de CSS (a continuación un ejemplo del selector de colores) y un buscador bastante mas práctico que el anterior:

Nuevas características de W8

Nuevas características de W8

Finalmente llego el momento de ejecutar nuestra app, así que le presionamos F5, esperamos a que compile y que no haya errores 😀 y a disfrutar de nuestro lector del blog Metro!

Mi primera aplicación Metro corriendo en Windows 8

Mi primera aplicación Metro corriendo en Windows 8

Si bien en este ejemplo no lo he utilizado, podríamos perfectamente trabajar con librerías como jQuery, así que seguimos sumando puntos a favor los desarrolladores web! 🙂

Este ha sido un breve resumen de lo que podemos hacer en Metro, espero que les haya sido de utilidad y que les sirva como base para empezar a trabajar con todo lo nuevo que se viene! (….mejor dicho, que llegó!).

ASP.NET MVC 3: nuevo view engine RAZOR

Junto con la nueva versión del framework ASP.NET MVC, se liberó la primera versión de un nuevo view engine llamado Razor y que promete ser muy interesante!

Vayamos directamente al código para entender mejor el tema. Lo primero que debemos hacer es al momento de crear una nueva aplicación web ASP.NET MVC 3, es seleccionar como tipo de view engine a utilizar el nuevo Razor y no al tradicional ASP.NET (ASPX).

Seleccionando el view engine

Seleccionando el view engine

Ahora vamos a crear dos vistas iguales que simplemente muestran una lista de usuarios. La primer vista la haremos con el view engine tradicional de ASP.NET:

<table>
  <% foreach (var item in Model) { %>
  <tr>
    <td><%: item.Id %></td>
    <td><%: item.Name %></td>
  </tr>
  <% } %>
</table>

Como podemos ver nuestras sintaxis de apertura para escribir código es bastante molesta. Pero con Razor nuestro código queda mucho más prolijo gracias a que nuestra sintaxis de apertura es solamente el símbolo @:

<table>
  @foreach (var item in Model) {
  <tr>
    <td>@item.Id</td>
    <td>@item.Name</td>
  </tr>
  }
</table>

Esto nueva sintaxis nos permite generar vistas muchos más limpias y fáciles de leer. Simplemente agregando la @ al iniciar nuestros bloques de código ya es suficiente. Como verán al iniciar el bloque foreach no es necesario indicar el cierre del mismo nuevamente con la @, con solamente agregar la llave de cierre, Razor identifica el final del bloque.

Otra punto interesante es la forma en que definimos nuestras MasterPage. La definición de una MP con Razor sería más o menos de la siguiente manera:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>@View.Title</title>
</head>
<body>
  <div>
    @RenderBody()
  </div>
</body>
</html>

Como podemos observar, el contenido de las vistas que utilicen esta plantilla será reemplazado donde se encuentra el método RenderBody() (mucho más prolijo que los content de ASP.NET, no?). Una vista que utiliza una MP debería hacerlo de la siguiente manera:

@model IEnumerable<MvcTres.Controllers.User>
@{
  View.Title = "Index Usuarios";
  Layout = "~/Views/Shared/_LayoutPage1.cshtml";
}
<table>
@foreach (var item in Model) {
  <tr>
    <td>@item.Id</td>
    <td>@item.Name</td>
  </tr>
}
</table>

Simplemente se crea un bloque donde especificamos cual será la plantilla que vamos a utilizar asignandosela a la propiedad Layout. Además podemos agregar distintas secciones de HTML a nuestras vistas utilizando el método RenderSection(…).

Otra característica interesante es que las páginas no tienen más la extensión aspx, sino que son cshtml o vbhtml, dependiendo del lenguaje seleccionado.

Entre las ventajas encontradas podemos nombrar:

– Reduce al máximo la cantidad de caracteres a escribir en nuestras vistas, lo que permite un código más limpio y simple de leer.
– Es fácil de aprender, ya que permite trabajar con HTML y C# al igual que el motor de ASP.NET.
–  Integra código y HTML como un todo.
– Soporta bloques multi-lineas.

Dos desventajas que note es que por ahora esta versión del view engine no soporta la vista HTML en Visual Studio y tampoco soporta el intellisense (aunque ya prometieron que sí para las próximas versiones!).

Para más info podemos visitar la siguiente entrada del blog de ScottGu’s que contiene muchísima info sobre este motor.

Update: Directiva @model

Razor provee también una nueva directiva llamada @model que nos permite hacer referencia a los modelos de una vista de una forma más limpia y concisa.

Veamos un ejemplo simple: con la directiva @inherits de ASP.NET MVC 3 Previews la forma de hacer la referencia con el modelo de la vista era la siguiente:

@inherits System.Web.Mvc.WebViewPage<IList<Sample.Models.User>>

Pero con la nueva directiva @model podemos definirlo de la siguiente manera:

@model IList<Sample.Model.User>

La sintaxis anterior es conceptualmente igual que antes, sin embargo es muchísimo más fácil de leer y escribir.

Stylecop en Visual Studio 2010

Esta disponible la versión 4.4.0 RTW de esta útil herramienta para refactorizar nuestro código y que ya habíamos comentado más en detalle anteriormente. Esta versión tiene como principal característica el soporte completo para Visual Studio 2010 y C# 4.0.

Stylecop

Stylecop

La descarga la pueden hacer desde el sitio oficial del proyecto. Les comento que para poder instalar la nueva versión, anteriormente tuve que desinstalar la versión que tenía en mi máquina.

Minimizando hojas de estilos y scripts con Visual Studio

Generalmente cuando queremos pasar nuestras aplicaciones web ASP.NET o MVC ASP.NET a producción lo hacemos a través de la opción Publicar de Visual Studio. Esto funciona bien en aplicaciones sencillas, pero no es siempre lo que necesitamos. Supongamos que necesitamos automatizar ciertos aspectos de la implementación, que en nuestro caso será minificar los archivos CSS y JS antes de crear la aplicación final. Para estos casos podemos usar los proyectos Web Deployment Project.

El primer paso para poder utilizar este tipo de proyectos (no vienen por default en Visual Studio) y poder minimizar los archivos será instalar lo siguiente:

En este caso vamos a crear una aplicación web ASP.NET MVC 2.0 que llamaremos MvcEjemplo y le vamos a agregar algunos archivos CSS y script JS, que luego vamos a minimizar. Además de la aplicación web vamos a agregar a la solución un proyecto del tipo Web Deployment Project donde vamos a realizar las configuraciones necesarias para poder minimizar nuestros archivos.

Para agregar este tipo de proyecto, primero seleccionamos la aplicación web, y luego vamos a la opción “Build > Add Web Deployment Project”. Seleecionada esta opción llamaremos a nuestro nuevo proyecto MvcEjemplo.Deploy.

Estructura de la solución

Estructura de la solución

Agregado el proyecto, vamos a realizar la primera configuración para que los cambios siempre se apliquen sobre nuestra aplicación en modo Release. Para ello hacemos click derecho sobre el proyecto y vamos a la opción “Properties Windows”, dentro de la misma lo configuramos de la siguiente forma:

Configurando el proyecto

Configurando el proyecto

Existen otras configuraciones que en el ejemplo no las vamos a ver, pero que pueden serles muy útiles.

Una vez terminados estos pasos, vamos a comenzar las modificaciones, para esto hacemos click derecho sobre el proyecto y vamos a la opción “Open Project File”, la cual nos va a desplegar el archivo de configuración (un documento XML) en donde vamos a trabajar:

Abriendo el archivo del proyecto

Abriendo el archivo del proyecto

En el archivo de configuración el primer paso será hacer referencia a la librería Ajax Minifier, que nos va a proporcionar los métodos necesarios para poder minimizar nuestros archivos:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\MicrosoftAjax\ajaxmin.tasks" />

La secciones dentro del XML de configuración que nos interesan en este caso son las encerradas dentro de los tags Target. El primero que vamos a modificar es el target “AfterMerge“. Dentro del mismo lo que vamos hacer es unificar todos los scripts JS del directorio “Script” (no tenemos en cuenta los que se encuentran en “Script\MyScripts” y nuestras hojas de estilos CSS en un único archivo para cada tipo (aclaro que unificamos dichos archivos en uno solo, ya que estos scripts y estilos suponemos se utilizan en todo el sitio y se referencian una única vez). Para esto agregamos lo siguiente:

<ItemGroup>
   <JsFiles Include="$(TempBuildDir)\Scripts\*.js;" Exclude="$(TempBuildDir)\Scripts\*.min.js;" />
   <CssFiles Include="$(TempBuildDir)\Content\*.css;" />
</ItemGroup>

Lo que hicimos fui incluir todos los archivos de script “JS” que se encuentran en el directorio “Scripts/” excepto los que terminen con la extensión “.min.js” (ya que los mismos ya se encuentran minimizados). Hacemos lo mismo con los archivos “CSS” que se encuentran en el directorio “Content” solo que en este caso no estamos excluyendo ninguno.

Hecho este paso, vamos a decir que todos los scripts que incluimos los escriba en un único archivo llamado AllJs.js:

<!-- Scripts Js -->
<ReadLinesFromFile File="%(JsFiles.Identity)">
   <Output TaskParameter="Lines" ItemName="jsLines" />
</ReadLinesFromFile>
<WriteLinesToFile File="$(TempBuildDir)\Scripts\AllJs.js" Lines="@(jsLines)" Overwrite="true" />

Para los archivos de estilos hacemos lo mismo pero en el archivo AllCss.css:

<!-- Css -->
<ReadLinesFromFile File="%(CssFiles.Identity)">
   <Output TaskParameter="Lines" ItemName="cssLines" />
</ReadLinesFromFile>
<WriteLinesToFile File="$(TempBuildDir)\Content\AllCss.css" Lines="@(cssLines)" Overwrite="true" />

Ahora vamos a trabajar en el Target “AfterBuild“. Lo que vamos a hacer es definir que archivos queremos minimizar, en nuestro caso los dos archivos que acabamos de “crear” y los script del directorio “MyScripts” por separados:

<ItemGroup>
   <JS Include="**\Scripts\AllJs.js;" />
   <JSMyScripts Include="**\Scripts\MyScripts\*.js;" />
</ItemGroup>
<ItemGroup>
   <CSS Include="**\Content\AllCss.css;" />
</ItemGroup>

Lo siguiente es “minimizar” dichos archivos:

<AjaxMin JsSourceFiles="@(JS)"
          JsSourceExtensionPattern="\.js$"
          JsTargetExtension=".min.js"
          CssSourceFiles="@(CSS)"
          CssSourceExtensionPattern="\.css$"
          CssTargetExtension=".min.css" />
<AjaxMin JsSourceFiles="@(JSMyScripts)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".min.js" />

Finalmente podemos “eliminar” aquellos archivos que fueron minimizados y que no van a ser utilizados por tal motivo, por ejemplo:

<ItemGroup>
  <DeleteAfterBuild Include="$(OutputPath)Scripts\*.js" Exclude="$(OutputPath)Scripts\*.min.js" />
  <DeleteAfterBuild Include="$(OutputPath)Scripts\MyScripts\*.js" Exclude="$(OutputPath)Scripts\MyScripts\*.min.js" />
  <DeleteAfterBuild Include="$(OutputPath)Content\*.css" Exclude="$(OutputPath)Content\*.min.css" />
</ItemGroup>
<Delete Files="@(DeleteAfterBuild)" />

En nuestra aplicación web vamos a referenciar los scripts de dos formas diferentes, según se trate de la aplicación en modo debug (podríamos decir en desarrollo) o no (en producción):

<%if (HttpContext.Current.IsDebuggingEnabled){%>
<link href="../../Content/Site.css" rel="stylesheet" type="text/css" />
<link href="../../Content/Style1.css" rel="stylesheet" type="text/css" />
<link href="../../Content/Style2.css" rel="stylesheet" type="text/css" />
<script src="../../Scripts/jquery-1.4.1.min.js" type="text/javascript"></script>
<script src="../../Scripts/ScriptJquery1.js" type="text/javascript"></script>
<script src="../../Scripts/ScriptJquery2.js" type="text/javascript"></script>
<script src="../../Scripts/MyScripts/Script2.js" type="text/javascript"></script>
<script src="../../Scripts/MyScripts/Script1.js" type="text/javascript"></script>
<%} else { %>
<link href="../../Content/AllCss.min.css" rel="stylesheet" type="text/css" />
<script src="Scripts/jquery-1.4.1.min.js" type="text/javascript"></script>
<script src="Scripts/AllJs.min.js" type="text/javascript"></script>
<script src="Scripts/MyScripts/Script2.min.js" type="text/javascript"></script>
<script src="Scripts/MyScripts/Script1.min.js" type="text/javascript"></script>
% } %>

Nota: si bien esto es algo molesto de hacer (sobre todo si en cada vista donde referenciamos a un script debemos preguntar por lo mismo), lo podemos solucionar ,por ejemplo, por medio de HTML Helpers o utilizando otro mecanismo que nos automaticen esta tarea.

Finalmente hacemos el “Build” de nuestro nuevo proyecto y validamos que no haya errores:

Compilando el proyecto

Compilando el proyecto

El resultado lo encontramos dentro de la carpeta Release del proyecto:

Proyecto de salida con archivos minimizados.

Proyecto de salida con archivos minimizados.

Comparando un poco los resultados podemos ver cuanto más prolijo y liviano quedan las llamadas a nuestros scripts y hojas de estilos (en la primer imagen veremos los resultados sin minimizar y en la siguiente nuestros archivos “optimizados”):

Aplicación sin archivos minimizados

Aplicación sin archivos minimizados

Aplicación con archivos minimizados

Aplicación con archivos minimizados

Espero que les sea util, y no dejen de ver los otros tipos de configuraciones que nos ofrece los proyectos Web Deployment Project ya que van a encontrar cosas muy interesantes.

Conociendo a C# 4.0: Programación dinámica

Tengo que contarles que desde hace tiempo vengo programando en C# y la verdad es uno de mis lenguajes preferidos, el que más conozco y con el que me siento más cómodo. Recientemente salió la versión 4.0 y trajo algunas novedades que son más que interesantes.

Uno de los cambios principales en C# 4.0 radica en la programación dinámica, es por eso que en este primer post nos vamos a centrar en esta nueva característica.

Pero qué es un lenguaje dinámico?  Un lenguaje dinámico realiza ciertos tipos de tareas en tiempo de ejecución que a diferencia de los lenguajes estáticos se hacen en tiempo de compilación, algunas de estas tareas son re-definir o alterar tipos de datos, analizar expresiones…

Algunos ejemplos de lenguajes dinámicos son:

– Python (antes que diga algo Ariel :))
–  Ruby
–  Visual Basic y COM con su capacidad para hacer late binding

Comencemos con C# 4.0 ahora!

Tipo dynamic

En esta versión surge un nuevo tipo de datos llamado dynamic, que es la forma en que .NET le dice al compilador que no verifique los datos en tiempo de compilación y si lo haga en tiempo de ejecución, que queremos decir con esto, que errores como validaciones de tipo de datos, solo aparecerán cuando estemos ejecutando nuestro programa.

Vayamos al grano, supongamos que tenemos definido lo siguiente:

dynamic dinamico = "hola";

El compilador hasta que no ejecutemos esa porción de código, no sabe que tipo de objeto es la variable dinamico. Por lo tanto podríamos tener lo siguiente sin que nos de error en tiempo de compilación:

dynamic dinamico = "hola";
int suma = 1 + dinamico;

Ahora en tiempo de ejecución cuando lleguemos a dicha línea nos dará un error de tipo de conversión de datos, lo cual es lógico 🙂 .

Veamos otro ejemplo, supongamos que tenemos la clase definida de la siguiente manera:

public class Cuenta
{
    public Cuenta()
    {
        this.Saldo = 0;
    }

    decimal Saldo { get; set; }

    public void Depositar(decimal monto)
    {
        this.Saldo += monto;
    }
}

Ahora veamos cómo funciona nuestro tipo de datos dinámico:

Cuenta cuentaEstatica = new Cuenta();
cuentaEstatica.Depositar(1000, 100); // Error en tiempo de compilación: cantidad de parámetros incorrectos

dynamic cuentaDinamica = new Cuenta();
cuentaDinamica.Depositar(1000, 100);

Como podremos ver, la cuenta estática no nos permitirá compilar nuestra aplicación, ya que el método Depositar no acepta dos argumentos, a diferencia de nuestra cuenta dinámica que “sí” nos permite poner dos parámetros al método Depositar y compilar nuestra aplicación, pero porqué? … porque dicha expresión recién será resuelta en tiempo de ejecución.

Dynamic no es var

Leyendo lo anterior, alguien podría preguntarse, el tipo de datos dynamic no es lo mismo que var?, la respuesta es no.

Vemos el siguiente ejemplo:

dynamic tipoDinamico = "1";
var tipoVar = "1";

int sumaDinamica = 1 + tipoDinamico;
int sumaVar = 1 + tipoVar; // Error de tipo en tiempo de compilación

Si probamos compilar esta porción de código, vamos a ver que la línea 4 nos va a dar error de tipos. En este caso para el tipo var es el compilador el que infiere el tipo de datos, por lo tanto ya lo conoce antes de ejecutarlo (tipoVar sigue siendo un valor tipeado estático).

Dynamic no es object

Actualmente cuando algún método recibía o devolvía algún objeto del cual desconocíamos su tipo, utilizábamos el tipo object. Un método que retorna un tipo object pone a disposición del desarrollador la transformación al tipo que verdaderamente necesita.

Veamos el siguiente ejemplo:

public static class AdministradorDeCuentas
{
    public static object DevolverCuentaUsuario(int id)
    {
         Cuenta cuenta = new Cuenta();
         …
        return cuenta;
    }
}

Supongamos que tenemos una clase que se encarga de administrar cuentas, y un método que nos retorna un object que en este caso representaría una cuenta (no tiene demasiado sentido que devuelva un tipo object, pero a fines del ejemplo nos sirve).

Ahora supongamos que obtenemos dos “cuentas” de la siguiente forma:

dynamic cuentaDinamica = AdministradorDeCuentas.DevolverCuentaUsuario(1);
cuentaDinamica.Depositar(1000);

object cuentaObject = AdministradorDeCuentas.DevolverCuentaUsuario(1);
cuentaObject.Depositar(1000); // Error en tiempo de compilación

Como podemos ver, la cuenta dinámica si nos permite invocar al método Deposito, ya la misma será evaluada en tiempo de ejecución. En cambio, la cuenta object no se ejecutará ya que el compilador no sabe de qué tipo se trata, por lo tanto para poder hacer el depósito deberíamos tener que hacer una conversión de tipos previamente.

Espero que le sea de utilidad. Les dejos el enlace a 2 post con muy buena informaci[on sobre el tema: Miguel Angel Morán y  C# LifeStyle .

Solucionando error ‘Invalid temp directory’ de los ASP.NET Chart Control

Una de las cosas que me puso muy feliz es la facil integración de los controles ASP.NET Chart con ASP.NET MVC (en mi caso la versión 2.0). Trabajando de forma local no tuve inconvenientes con el control, pero al momento de publicar la aplicación apareció el siguiente error:

Invalid temp directory in chart handler configuration [c:\TempImageFiles\].

Investigando me encontré que el problema es una cuestión de configuración: el chart control busca dentro de nuestro web.config en las AppSettings una key llamada “ChartImageHandler”. Esta tiene definida cuestiones relacionadas a la forma de almacenamiento del chart, timeouts, y la ubicación física donde guarda la imagen generada. Por defecto el control crea la siguiente entrada en nuestro web.config :

<add key="ChartImageHandler" value="storage=file;timeout=20;dir=c:\TempImageFiles\;" />

En el caso de no que no haya creado la key en el web.config, la ubicación física por defecto donde crea las imagenes será el directorio “c:\TempImageFiles\”.

Cómo solucionar este problema?, agregando o modificando la siguiente key en nuestro web.config:

<add key="ChartImageHandler" value="storage=file;timeout=20;" />

Espero que les haya sido útil, saludos.