WP8SDK: Saca la cartera

Para subirse al tren del nuevo Windows Phone 8 y correr su SDK toca pasar por caja. No, el SDK es gratis como siempre, también el VS 2012 Express que incluye, pero algo tienes que poner tú, ¿no? 

  1. Necesitas un Win8 Pro (no vale Std) para que tire el emulador que usa HyperV. Pero el Pro vale sólo 30 € en España.
  2. De paso, si no tienes cuenta de la Store, ahora tienes 7 días para conseguirla por $8.
    Te cobran $99 pero te devuelven la diferencia en 30-45 días, como explican en el DevCenter.

Total, que Microsoft quiere tu dinero y por eso ha ajustado muuucho sus precios. Pero las cantidades son tan bajas que espero que a nadie le suponga un impedimento para lanzarse a por el SDK. El principal gasto, que es el Win8, tiene muchas más ventajas: aparte de las visuales y las mejora de rendimiento, te permite también desarrollar apps para la Windows 8 Store.

Lo que te puede costar más es el PC: tiene que soportar virtualización, mira este post de Rafa Serna sobre cómo verificar los requisitos con la tool coreinfo.

Así que mucha suerte.

Un placer.

 

| 2 comentarios

[Entity Framework] ON DELETE CASCADE por defecto nunca más

Voy a ser muy conciso: Entity Framework aplica ON DELETE CASCADE por defecto a las relaciones requeridas. Esto es una mala decisión para un framework de uso general, porque a) muchos desarrolladores no lo saben, lo que puede conducir a acciones peligrosas, y b) es fácil olvidarse de desactivarlo. Sí, desactivarlo, porque esta mala decisión tiene una cara positiva: es muy fácil de quitar, sólo una línea para retirar una convención.

Por suerte, usar SQL Compact Edition como BD durante las primeras etapas de un desarrollo me suele avisar de este olvido. Otro día podemos hablar más de esta técnica. La cuestión hoy es ¿cómo me avisa? Muy sencillo: porque hay patrones de ON DELETE CASCADE que SqlCe no soporta, y da un error, aunque no muy descriptivo. Vamos a verlo con un sencillo ejemplo.

Montar una aplicación EF + SqlCe en 5 pasos

Vamos a crear un modelo con 3 entidades: Cliente, Ticket (que tiene un cliente) y Pago (que tiene un Cliente y un Ticket). Sí, ya sé que es redundante y no es 3NF, pero así tiene que ser. Además, todas esas relaciones serán requeridas.

1 Crear un nuevo proyecto de consola (también puede ser WPF o MVC, lo que más os guste).

2 Añadir el paquete de nuget EntityFramework.SqlServerCompact (¿Que no sabéis? Pues no sigáis leyendo. Yo sólo quiero lectores vagos, como buenos informáticos).

3 Crear el modelo. Como buenos vagos, podéis copiar y pegar esto (aunque he metido un compiler error… sólo por fastidiar a los vagos, que me caen mal):

public class DemoDb : DbContext {
    public DbSet<Cliente> Clientes { get; set; }
    public DbSet<Ticket> Tickets { get; set; }
    public DbSet<Pago> Pagos { get; set; }
}

public class Cliente {
    public int Id { get; set; }
    public string Nombre { get; set; }
}

public class Ticket {
    public int Id { get; set; }
    public string Numero { get; set; }

    public int ClienteId { get; set; }
    public Cliente Cliente { get; set; }

    public ICollection<Pago> Pagos { get; set; }
}

public class Pago {
    public int Id { get; set; }
    public DateTimo Fecha { get; set; }
    public decimal Importe { get; set; }

    public int ClienteId { get; set; }
    public Cliente Cliente { get; set; }
    
    public int TicketId { get; set; }
    public Ticket Ticket { get; set; }
}

(Por cierto, el artículo no es de WinRT, pero ¿a que los números de los pasos son muy Metro?)

4  Añadimos algo de código al Main para que conecte con (y cree) la base de datos:

static void Main(string[] args) {
    using(var db = new DemoDb()) {
        Console.WriteLine("Hay {0} clientes", db.Clientes.Count());
    }
}

5 El paso final: Ejecutar. EF creará una nueva base de datos TuNamespace.DemoDb.sdf… pero se producirá un error:

The referential relationship will result in a cyclical reference that is not allowed. [ Constraint name = FK_Pagoes_Tickets_TicketId ]

Dejando a un lado el Pagoes (aunque en realidad a mí no me importa que las tablas se llamen así. Total, eso sólo lo ven los DBA), ¿alguien entiende este error? “Cyclical reference” ¿dónde? Evidentemente no hay ningún ciclo, pero lo que le pasa a SqlCe es que no soporta todos los ON DELETE CASCADE que estamos definiendo. Como dijimos, cada una de las relaciones requeridas de antes es por defecto ON DELETE CASCADE, y SqlCe 4.0 no soporta los dos caminos de eliminación que se están generando: porque si eliminamos un cliente, los pagos se intentarán eliminar por 2 caminos:

Cliente –> Pago

Cliente –> Ticket –> Pago

No le doy mayor importancia a esta decisión en el diseño de SqlCe 4.0 (que sí podría tenerla), y reitero que esto sólo sucede en SqlCe, es decir, cualquier SQL Server desde el Express en adelante no tienen esta restricción ni por lo tanto daría este error: crearía la base de datos sin problemas. Sin problemas pero con los peligrosos ON DELETE CASCADE. ¿Qué pasa si un usuario avanzado (léase el programador) elimina un cliente? Que todos sus tickets y pagos se borran. Sin más aviso. Y sin vaselina.

Solución

La solución para ambos problemas (a saber, para los despistados, uno, poder generar la base de datos en SqlCe, y dos, protegernos de eliminaciones accidentales de datos en el resto de motores) es eliminar la convención de que cada relación requerida sea ON DELETE CASCADE. Esta convención es una de las muchas que vienen activadas por defecto en nuestro modelo de DbContext, y quitarla es tan sencillo como añadir esto (en nuestro caso en la clase DemoDb):

protected override void OnModelCreating(DbModelBuilder modelBuilder) {
    modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();
}

Si ahora volvemos a ejecutar el proyecto, SqlCe creará la base de datos sin más error. Bueno, no, porque antes falló a mitad de su creación por lo que antes hay que eliminar ese archivo (por defecto, SqlCe crea su base de datos en \Bin\Debug con extensión .sdf).

De ahora en adelante, un intento de eliminar un cliente que tenga Tickets y/o Pagos dará un error. Y si queremos activar ON DELETE CASCADE para alguna relación en particular, después de sopesarlo y con todas sus consecuencias, podemos hacerlo con la API fluida de definición del modelo, método WillCascadeOnDelete.

Conclusión

Otro día podemos hablar de la conveniencia de usar SqlCe en las etapas más tempranas del desarrollo de una aplicación. A mí, entre otras cosas, me sirve como recordatorio de eliminar esta convención. También podéis poneros una alarma en el móvil, pero recordad que “OneToManyCascadeDeleteConvention is evil”.

| Deja un comentario

[WPF] Desnudando el TabControl: ajustar las pestañas en una fila

Después de bastante tiempo sin ponerme ante esta página, hoy he encontrado algo de tiempo y una excusa adecuada en las opciones de personalización que nos ofrece el control TabControl de WPF.

El hecho es que si añadimos más pestañas de las que caben en el control, se crea una segunda línea de pestañas para alojarlas:

image

Este comportamiento que en general es suficiente, en ocasiones puede no ser lo que deseamos para nuestra aplicación. En mi caso, necesitaba que al reducir el ancho de la ventana no se cree una segunda fila, sino que se estrechen las pestañas para ajustarse al ancho disponible.

Desnudando el TabControl

El modelo de extensibilidad de WPF permite atacar este problema con sencillez. Para esto, debemos conocer la composición del TabControl: internamente, utiliza un control TabPanel para mostrar las pestañas, y un ContentPresenter para el contenido de la pestaña seleccionada. El mencionado control TabPanel proporciona un diseño muy específico: es similar a un WrapPanel, ya que cuando los controles no caben saltan a la siguiente línea, pero con la particularidad de ajustar el contenido para abarcar toda la fila. Podemos ver el TabControl por dentro sustituyendo su Template por esta sencilla plantilla:

        <TabControl Margin="10" Height="80">
            <TabControl.Template>
                <ControlTemplate TargetType="TabControl">
                    <DockPanel>
                        <TabPanel DockPanel.Dock="Top"
                                  IsItemsHost="True"/>
                        <Border Background="{TemplateBinding Background}" 
                                BorderThickness="{TemplateBinding BorderThickness}" 
                                BorderBrush="{TemplateBinding BorderBrush}">
                            <ContentPresenter Name="PART_SelectedContentHost" 
                                              Margin="{TemplateBinding Padding}" 
                                              ContentSource="SelectedContent" />
                        </Border>
                    </DockPanel>
                </ControlTemplate>
            </TabControl.Template>
            <TabItem Header="Tab 1">

Si lo probamos, ahora el TabControl se dibujará de forma ligeramente distinta:

image

Aunque a grandes rasgos es el mismo diseño, por la simplicidad de la plantilla utilizada se ha descuadrado ligeramente el diseño. No es esto lo que me interesa, sino identificar que el responsable de dibujar las pestañas es el control TabPanel, lo que nos va a permitir sustituirlo por otro y conseguir otros comportamientos.

Usando un WrapPanel

Simplemente con sustituir la etiqueta TabPanel por WrapPanel (el resto de propiedades se mantiene igual), el diseño del control cambia automáticamente:

image

Evidentemente el diseño no ha mejorado, pero vemos lo sencillo que es realizar cambios una vez que nos hemos hecho con la plantilla del control.

Usando un StackPanel

Vamos a probar a usar un StackPanel horizontal. Cambiamos el WrapPanel por:

<StackPanel DockPanel.Dock="Top" Orientation="Horizontal"
            IsItemsHost="True"/>

Y obtenemos:

image

La última pestaña, Tab 7, no cabe y no hay forma de hacerla visible si no es ampliando el tamaño de la ventana. Pero veamos cómo podemos añadir la posibilidad de desplazarnos a esas pestañas ocultas.

Usando un StackPanel y un ScrollViewer

Vamos a incluir el StackPanel dentro de un ScrollViewer:

<ScrollViewer DockPanel.Dock="Top" 
                HorizontalScrollBarVisibility="Auto" 
                VerticalScrollBarVisibility="Disabled">
    <StackPanel Orientation="Horizontal"
                IsItemsHost="True"/>
</ScrollViewer>

Aunque el diseño no es muy atractivo, ya tenemos la posibilidad de desplazarnos a los elementos no visibles:

image

Este diseño puede potenciarse:

  • Para pantallas táctiles, ocultando la barra horizontal (Hidden) y activando el PanningMode=”HorizontalOnly” que permitirá desplazarnos arrastrando las pestañas con el dedo.
  • Incluyendo botones de desplazamiento incrustados junto a las pestañas, lo que puede conseguirse cambiando el Template del ScrollViewer. Más información en este buen post de Olaf Rabbachin.

Pero no era esto lo que yo pretendía: mi objetivo era ajustar al ancho disponible. Lo primero que pienso es un Grid.

Por qué no uso un Grid

Evidentemente, para conseguir ese ajuste podemos crear un Grid con 7 columnas de tamaño proporcional (Star – *) y situar cada pestaña en una de ellas. El problema es que para esto necesitamos definir la propiedad adjunta Grid.Column en cada cabecera de pestaña, lo que no es sencillo. Bueno, el concepto de sencillez es diferente para cada uno, pero los buenos informáticos somos vagos (eso me digo para consolarme ;) e intentamos conseguir más con menos.

Si recopilamos, hasta ahora no hemos tenido que establecer ninguna propiedad en los ítems para conseguir los diseños, por lo que vamos a intentar otra aproximación con un control de uso poco frecuente.

Usando un UniformGrid

El control UniformGrid es un Grid simplificado donde definimos sólo el número de filas y columnas, y se creará una cuadrícula con filas y columnas del mismo tamaño. Además, los elementos no hay que asignarlos a cada fila o columna, sino que se asignan por orden: el primer control a la primera celda, el siguiente a la segunda, así hasta completar la fila, luego la segunda fila y así hasta que no queden más ítems. Por lo cual podemos usar como contenedor sólo esto:

<UniformGrid DockPanel.Dock="Top" Columns="7" Rows="1" IsItemsHost="True"/>

Con el UniformGrid tenemos el ajuste que buscábamos:

image

image

El ajuste y los bordes puede mejorarse si se sigue más fielmente la Template original del TabControl. Yo he procurado simplificar las plantillas para que sea más fácil seguir los ejemplos, sacrificando este nivel de detalle.

Mi versión final

Aunque la solución que hemos introducido con UniformGrid tiene un defecto: necesita conocer el número de pestañas para asignar Columns=”7”. Pero vamos a solucionar esto usando un sencillo truco: si definimos Rows=”1” pero no definimos el número de columnas, se crearán tantas columnas como pestañas existan. Así que sólo tenemos que eliminar la propiedad Columns, y finalmente nos queda:

        <TabControl Margin="10" Height="80">
            <TabControl.Template>
                <ControlTemplate TargetType="TabControl">
                    <DockPanel SnapsToDevicePixels="true" ClipToBounds="true">
                        <UniformGrid DockPanel.Dock="Top" Rows="1" IsItemsHost="True"/>
                        <Border Background="{TemplateBinding Background}" 
                                BorderThickness="{TemplateBinding BorderThickness}" 
                                BorderBrush="{TemplateBinding BorderBrush}">
                            <ContentPresenter Name="PART_SelectedContentHost" 
                                              SnapsToDevicePixels="{TemplateBinding SnapsToDevicePixels}" 
                                              Margin="{TemplateBinding Padding}" 
                                              ContentSource="SelectedContent" />
                        </Border>
                    </DockPanel>
                </ControlTemplate>
            </TabControl.Template>
            <TabItem Header="Tab 1">
                <TextBlock Text="With UniformGrid"/>
            </TabItem>
            <TabItem Header="Tab 2"/>
            <TabItem Header="Tab 3"/>
            <TabItem Header="Tab 4"/>
            <TabItem Header="Tab 5"/>
            <TabItem Header="Tab 6"/>
            <TabItem Header="Tab 7"/>
        </TabControl>

El control UniformGrid está sólo disponible en WPF, pero es muy sencillo de implementar en Silverlight y otras plataformas XAML, como muestra Jeff Wilcox en este post.

Un placer.

| Deja un comentario

De cómo en AspNetMVC prevalece QueryString sobre el propio Modelo

Imaginemos una página MVC muy sencilla: un buscador con dos datos, el texto a buscar y una casilla para indicar si se quiere coincidencia estricta de mayúsculas o no. La búsqueda se ejecuta mediante un botón y los resultados se muestran en la misma página tras un roundtrip completo al servidor, sin AJAX. Para construir esta página, vamos a elaborar sus tres piezas M.V.C.

Modelo

Una clase ViewModel con los parámetros de la búsqueda y con una lista de resultados.

public class BuscarViewModel
{
    public string Texto { get; set; }
    public bool EnMayusculas { get; set; }
    public IEnumerable<dynamic> Resultados { get; set; }
}

Controlador

Una acción Buscar de tipo GET que recibe los parámetros de la búsqueda. Por simplicidad, uso el mismo ViewModel como parámetro de entrada, para aprovechar el trabajo del ModelBinder de MVC. La acción rellena el valor de Resultados, en teoría considerando los parámetros de búsqueda, aunque en este caso he usado valores de ejemplo.

Imaginemos también una peculiar regla de negocio que nos exige que la casilla “Coincidir mayúsculas” se devuelva siempre desmarcada, incluso si ha sido marcada en la búsqueda anterior. Para ello, en el modelo recibido la establecemos a falso.

public ActionResult Buscar(BuscarViewModel buscarViewModel)
{
    buscarViewModel.EnMayusculas = false;                         //Siempre se pone a falso
    var ejemplo = new {Texto = "Ejemplo" };
    buscarViewModel.Resultados = Enumerable.Repeat(ejemplo, 50);  //Ficticio
    return View(buscarViewModel);
}

Esta acción responde a las siguientes URI (suponiendo un controlador EntidadController):

  • /Entidad/Buscar
  • /Entidad/Buscar?Texto=abc&EnMayusculas=true

Vista

Una vista muy sencilla podría ser:

@model MvcCheckBoxForFail.Models.BuscarViewModel
@{
    ViewBag.Title = "Buscar";
    var grid = new WebGrid(Model.Resultados);
}

<h2>Búsqueda</h2>
@using (Html.BeginForm("Buscar", "Entidad", FormMethod.Get)) {
    <fieldset>
        <legend>Buscar @Model.Texto en mayúsculas @Model.EnMayusculas</legend>

        <div>
            Texto
            @Html.EditorFor(model => model.Texto)
            Mayúsculas
            @Html.EditorFor(model => model.EnMayusculas)
            <input type="submit" value="Buscar" />
        </div>

        @grid.GetHtml()

    </fieldset>
}

Sus elementos principales son:

  • Un WebGrid nativo de MVC para mostrar los resultados con una sencilla paginación en servidor.
  • Un Form con método GET.
  • Los campos para el texto y para forzar la coincidencia de mayúsculas, generados ambos con EditorFor.

Problemática

Si probamos esta sencilla página, nos encontraremos con un curioso comportamiento: no sigue la regla de que la casilla de forzar mayúsculas debe salir siempre desactivada. Por el contrario, mantiene el valor usado para la búsqueda. Pero nosotros hemos asignado false claramente en el controlador, por lo que ¿quién es el responsable de que se muestre la casilla activada? A este nivel, el culpable es el método EditorFor, que no usa el valor que trae el modelo (sí, de ahí el resaltado amarillo, soy muy malo para mantener el suspense). Más adelante depuraremos mejor las responsabilidades.

Antes de eso, probamos con otras opciones. Por ejemplo, en lugar de EditorFor, usaremos CheckBoxFor:

@Html.CheckBoxFor(model => model.EnMayusculas)

El comportamiento, como era de esperar, es idéntico. Así que vamos un paso más allá y usamos el método CheckBox:

@Html.CheckBox("EnMayusculas", Model.EnMayusculas)

Para nuestra sorpresa, el comportamiento sigue siendo el mismo, aún cuando Model.EnMayusculas es siempre falso. Pero es más, si escribimos:

@Html.CheckBox("EnMayusculas", false)

Incluso indicando el valor de false explícitamente, el input se renderiza marcado (checked) en ciertas ocasiones. ¿Cómo es esto posible?

Primera explicación

En primer lugar, ya hemos identificado en qué casos se activa la casilla: cuando estaba marcada al hacer la búsqueda, es decir, cuando se recibe en la QueryString un EnMayusculas=true.

NOTA: En la QueryString se recibirá siempre un EnMayusculas=false, independientemente de que se marque o no la casilla. Esto es debido al hidden que genera CheckBoxFor. Para más información sobre este comportamiento, ver esta respuesta de Jeremy.

¿Qué se deduce de aquí? Pues que al usar los métodos del helper Html para renderizar un control (no sucede sólo con el CheckBox, probadlo con otros), si el nombre indicado existe en la QueryString recibida, se usará ese valor independientemente de su valor en el modelo o del valor estricto que le pasemos al helper. Hay más información sobre este comportamiento en esta incidencia respondida por RanjiniM de forma contundente: “Este es el comportamiento esperado en ASP.NET MVC”.

Soluciones

Ante esto, pueden buscarse distintas soluciones. Yo voy a plantear las dos más extremas.

La primera es dejar de usar el helper CheckBox e insertar un input en HTML directamente. Incluso podemos elaborar nuestro propio helper que evite este comportamiento.

Pero antes veamos la segunda solución, que es la que propone RanjiniM en la respuesta anterior: excluir la propiedad en cuestión del uso del ModelBinder. La firma de la acción incluirá un nuevo atributo, quedando así en nuestro controlador:

public ActionResult Buscar([Bind(Exclude="EnMayusculas")] BuscarViewModel buscarViewModel)

El atributo se aplica al parámetro, no al método completo, y define la propiedad (o propiedades, separadas por comas) para las que queremos evitar el comportamiento descrito. Una vez establecido este atributo, el código original (usando CheckBoxFor) funciona correctamente, y la casilla sale desmarcada en todos los casos.

ModelBinder y ValueProvider

Con la ayuda de Luis Ruiz Pavón y de Eduard Tomàs he revisado cómo puede afectar el orden de definición de los ValueProvider a esta incidencia, pero mis pobres conocimientos no me han permitido llegar a una conclusión.

Yo entiendo que tanto el ModelBinder como los ValueProvider se utilizan a la hora de generar el modelo, es decir, de construir la instancia que se pasa como argumento a la acción Buscar. Pero una vez generada esa instancia de BuscarViewModel, no consigo entender por qué vuelve a prevalecer el valor de QueryString sobre lo que pone en el modelo. Si los valores de QueryString ya se han trasladado al modelo, lo lógico después es trabajar con el modelo, que puede haber sufrido cambios como en nuestro supuesto.

La intención de toda esta exposición es doble: en primer lugar, servir de ayuda a quien pueda encontrarse esta misma incidencia; y por otro lado, tratar de comprender mejor la justificación de este comportamiento, que según afirma RanjiniM no es un bug sino el comportamiento esperado (a no ser que estemos disfrazando un bug de feature como tantas veces ;) Por eso agradezco vuestros comentarios y opiniones al respecto.

Un placer.

| 2 comentarios

[ASP.NET MVC] Detectando DEBUG en código y en Razor

Últimamente he aumentado bastante mi productividad usando un mecanismo muy sencillo: implementando código sólo para depuración que me ayuda en las sesiones de depuración, y ahora no me estoy refiriendo a trazas ni logs. Me refiero a cosas tan sencillas como:

  • Iniciar sesión automáticamente con un usuario y contraseña dados (suponiendo, como en mi proyecto, que se prohíbe por requisito que el navegador recuerde al usuario).
  • Rellenar valores de mi conveniencia en un formulario.

Como estas cosas, aunque las implemente, no quiero que ni por lo más remoto puedan llegar a producción, uso la constante de compilación DEBUG que indica si estamos ejecutando en Debug o en Release (y si tenemos más configuraciones, podremos indicar si la queremos declarar o no). Como mi código en producción irá como Release, no corro el riesgo de ejecutar mis atajos para depuración.

En un proyecto web MVC, según dónde nos encontremos, la forma de detectar si estamos en Debug o Release es distinta como vamos a ver a continuación.

Directivas de precompilación y DEBUG

Las directivas de precompilación de C# permiten que el compilador considere un código u otro en función de unas constantes, como DEBUG en nuestro caso. Por ejemplo, algo como:

#if DEBUG
        string username = "pablo";
#else
        string username = null;
#endif

Hace que los programas generados en Debug y en Release sean distintos: uno llevará una asignación a “pablo” y el otro a null. Ojo que no existe doble declaración de la variable: en un caso se declarará una y el propio compilador ignorará la otra línea, no sólo no se ejecuta, es que ni se compila.

Usando estas directivas no corro el riesgo de olvidarme de quitar este código de depuración cuando genere mi versión para producción: se usará el código que asigna null.

Un código similar he usado en mi MembershipProvider (no pongo el ejemplo porque mi caso es muy particular y dependiente de un motor de bases de datos muy particular) para iniciar una sesión concreta siempre en Debug, mientras que en Release el usuario debe iniciar sesión.

Las directivas de precompilación tienen más usos, como usar un mismo código base para diferentes targets, como Silverlight, Windows Phone… con algo como:

#if SILVERLIGHT

Lo cual nos acerca a aquello de un código, tres pantallas. Aunque no es el tema de hoy.

Detectando modo Debug en Razor

Pensando bien, uno interpreta que esto se puede aplicar al código C# incrustado en Razor. Yo he intentado usarlo para el segundo punto planteado al inicio de este artículo, y de forma natural uno piensa que puede hacer:

@{
#if DEBUG
        string titulo = "pablo";
#else
        string titulo = null;
#endif
}

Cuidado, esto no funciona. Y tiene sentido que no lo haga: este código dentro de Razor no es compilado al publicar el proyecto, sino que es incrustado en las vistas, y luego las vistas son compiladas por IIS según necesidad. Por lo que #if DEBUG siempre devuelve true. No sirve.

Pero hay otra forma de detectar que estamos en Debug desde Razor, y aunque no es exactamente igual, en la mayoría de los casos será equivalente y nos servirá. Se trata de la propiedad:

Context.IsDebuggingEnabled

Que nos ofrecen las páginas Razor a través de su HttpContext. De esta forma sí podemos hacer:

@{
    string titulo;
    if(Context.IsDebuggingEnabled)
        titulo = "pablo";
    else
        titulo = null;
}

Con lo que podemos usar esa variable @titulo como valor del elemento input correspondiente para que al cargar la página tengamos un valor inicial. Ojo, esto se podría (debería) hacer en el modelo (viewmodel) usado en la página, pero entonces podríamos usar directivas de precompilación y no tendría gracia el uso de IsDebuggingEnabled, así que he forzado un poco el ejemplo para mostrar este caso.

Conclusión

Podemos hacer trucos en nuestro código que nos faciliten la tarea rutinaria de ejecutar una y otra vez una aplicación en desarrollo para llegar a la página que estamos implementando, saltando los pasos que un usuario debería recorrer. Esta simplificación puede aumentar considerablemente nuestra productividad, pero cuando lo hagamos, debemos seguir los cauces que existen para ello (detección de DEBUG con #if, propiedad IsDebuggingEnabled) para que al pasar la aplicación a producción no quede ni rastro de nuestros trucos. Y ojito también con lo que subimos al control de código fuente, a ver si otro compañero se va a encontrar con nuestros atajos y quizá no le vayan a hacer mucha gracia.

Un placer.

| Deja un comentario

Primer contacto con Code Contracts (no es un tutorial)

Hola, me llamo Pablo y hoy he sufrido mi primer contacto forzoso con Code Contracts. Lo de forzoso no es porque no me guste ese proyecto, sino porque ha sido completamente involuntario. Pero antes de nada, ¿qué es Code Contracts?

Code Contracts

Code Contracts es un proyecto de Microsoft Research para incluir en nuestro código las precondiciones y poscondiciones que deben cumplirse antes y después de su ejecución, así como los invariantes que deben cumplirse siempre. Muchos no habrán usado estas palabrejas desde que dejaron la Universidad, otros ni eso, pero al programar todos estamos asumiendo premisas que deben cumplirse (por ejemplo, que un método debe llamarse antes que otro, o que una variable tenga un rango de valores concreto), sólo que no los reflejamos en ningún sitio, sólo están en nuestra cabeza. Ahí es donde interviene Code Contracts, permitiendo poner negro sobre blanco (pixel negro sobre pixel blanco, quiero decir) esas condiciones, y además verificando que se cumplan tanto durante la ejecución de nuestro programa como de nuestros tests.

Como idea es muy interesante, y permite incrementar la calidad de nuestro código, difuminando un poco la división entre programa y tests, ya que estas comprobaciones (equivalentes a los Assert de un test) están en el propio programa. También ayuda a la legibilidad del código y a su comprensión por parte de quien venga detrás (que normalmente somos nosotros mismos dentro de un tiempo). Y su uso no es nada difícil, como muestra un botón:

public void Bind(FrameworkElement bindingObject, Func<FrameworkElement, FrameworkElement> bindingObjectParentFunc)
{
    Contract.Requires<ArgumentNullException>(bindingObject != null, "Binding object cannot be null.");
    Contract.Requires<ArgumentNullException>(bindingObjectParentFunc != null, "Binding object function cannot be null.");
…

En lugar de comprobar si nos han pasado bien los atributos con un if, lo estamos declarando usando Contract, el punto de acceso principal a la librería Code Contracts. Se entiende fácil, ¿verdad? Pues si queréis saber más, os dejo aquí una presentación de un chico que parece que sabe de esto.

¿Pero qué te ha pasado hoy?

Pues nada, que estaba tratando de localizar un error en la versión que estamos preparando para WPF de SilverDiagram, y entre cambios de código y recompilaciones de librerías me he encontrado con este error:

image

El texto es bastante más extenso, pero qué os voy a contar de esas hermosas pilas de llamadas listadas en enormes MessageBox. Todo un símbolo, y perfecto para demostrar a nuestro jefe/usuarios lo difícil que es nuestra profesión.

La cuestión es que este error viene provocado por Code Contract, porque se da una situación curiosa: Tengo dos librerías, A y B. La librería B referencia a A (pero están en soluciones distintas, así que referencia el ensamblado A.dll, pongamos).

Yo estaba probando B sin problemas, tratando de corregir el error, haciendo cambios y pruebas normalmente. Cuando identifico que el error parece estar en A, abro su solución, lo corrijo y compilo para usar esta nueva A.dll. Esta compilación no se queja.

Compilo B con la nueva A.dll y de nuevo sin problema. Pero al ejecutar, el error, ah, el error: Must use the rewriter when using Contract.Requires<TException>.

Está claro que la culpa es de Code Contracts. Echo una búsqueda rápida, y encuentro en el blog de Derik Whittacker una coincidencia. Y hace especial hincapié en que la culpa no es de B, sino del proyecto A, a pesar de no haber dado errores en su compilación. Y el motivo es sencillo: no tengo instalado Code Contracts en mi ordenador.

Instalando… y solucionado

Así que tras cerrar los Visuales Estudios, descargo e instalo desde la web de Code Contracts (hay versión comercial y académica, pero no me preguntéis sobre eso). Una vez instalado, conseguimos dos cosas:

  1. En las Propiedades de los proyectos hay una nueva pestaña Code Contracts donde podemos definir el comportamiento de esta librería en nuestro proyecto.
  2. Al volver a compilar el proyecto, ya podemos usar A.dll con normalidad en otros proyectos (si estaba bien configurada la comprobación en tiempo de ejecución de las propiedades de Code Contracts, pero esto es harina de otro costal).

Espero que esto pueda servir de ayuda para quienes sufran el mismo problema, y también para que algunos nos empecemos a introducir en Code Contracts (…por mi primero).

Un placer.

| Deja un comentario

Carencias de Sql CE 4.0 en Visual Studio 2010

Hoy domingo he estado preparando una demo introductoria a Entity Framework, con el objetivo de que fuera lo más sencilla posible. Para ello, no he querido trabajar ni en un proyecto web ni en una aplicación Windows, sino en un proyecto de consola, para no exigir ningún conocimiento previo en el destinatario. Y desde un principio había elegido basarme en SQL Server Compact Edition (Sql CE), y su última versión 4.0, para evitar la necesidad de instalar un motor de bases de datos y profundizar en su configuración, pero todavía manteniendo un proveedor nativo de .net y de Entity Framework. Todo sobre Visual Studio 2010. También debo adelantar que mi contacto previo con Sql CE es mínimo, sólo como registro de Elmah y poco más. Pero como hoy he aprendido algunos hechos, los quiero compartir en este artículo.

Aunque yo suelo trabajar con EF aplicando la metodología Code-First, de nuevo por simplicidad decido plantear la demo como Model-First, por aquello del interfaz gráfico y demás (que está sobrevalorado, donde se ponga un buen interfaz de código fluido…). Bueno, creo un archivo .edmx y defino en él 2 tablas con su propio Id autonumérico como clave primaria y una clave foránea entre ambas. Cuando pido Crear base de datos a partir del modelo en el menú contextual, me pide crear una conexión a base de datos, y me ofrece 3 proveedores: SQL Server, archivo mdf y Sql CE 3.5.

image

Decido continuar con mi idea de usar CE aunque sea 3.5 (ya veré después… sólo estoy preparando una demo). Creo un nuevo archivo sdf para la conexión y Visual Studio me genera un archivo edmx.sqlce con el script de base de datos para generar las tablas. Lo conecto al sdf y ejecuto sin problemas. Pero al incluir código para crear una entidad y ejecutarlo, obtengo el error:

Server-generated keys and server-generated values are not supported by SQL Server Compact.

Lo cual no es del todo cierto, bueno, casi lo era cuando se escribió ese mensaje de error, ya que Sql CE 3.5 no soporta autonuméricos generados en el servidor a través de Entity Framework, es decir, realmente es una carencia del provider y no del motor. Con esto, Sql CE 3.5 no me sirve para mi sencillo ejemplo, donde no voy a montar ningún generador de claves. Esta carencia ha sido subsanada en Sql CE 4.0, así que doy marcha atrás y me lanzo a la búsqueda de esta versión.

Hasta ahora, cuando lo había necesitado (para Code-First y para Elmah) había usado el paquete nuget. Pero esto no sirve para EDMX, ya que debe estar registrado el proveedor en Visual Studio. De ahí que me descargo las SQL CE Tools for Visual Studio SP1 (que ya lo tenía) desde este artículo de ScottGu (no sé si también estará en español, he buscado un poco y no lo he encontrado). Pero tras instalarlo, me siguen saliendo los mismos proveedores que antes, por lo que investigo un poco y descubro que el proveedor Sql CE 4.0 sólo se ofrece en el EDMX dentro de proyectos web, no en mi humilde proyecto de consola. De hecho si en un proyecto web creo el sdf de la versión 4.0 y añado una conexión a él en el Explorador de servidores de Visual Studio, al tratar de usarlo desde el EDMX no se incluye en el combo (sólo se incluyen las conexiones con Sql CE 3.5 o con Sql Server). Es realmente desagradable ver cómo un EDMX añadido a una librería de clases (que es lo aconsejable, extraer el modelo fuera del proyecto web) sólo permite usar Sql CE 3.5 mientras que en un EDMX dentro de un proyecto web sí se ofrece Sql CE 4.0:

image

Todo esto me parece una situación extraña y limitadora, ya que Sql CE 4.0 es una solución ideal para pequeñas aplicaciones o utilidades, o para la primera fase de algunas aplicaciones mayores, incluso para instalaciones pequeñas de esas mismas aplicaciones; y con esta carencia se dificulta su utilización práctica para quienes prefieren usar el EDMX en lugar de la aproximación Code-First. Sólo me queda añadir que esta restricción puede salvarse siguiendo este truco (en inglés), que implica modificar el EDMX a mano, y que puede servir a los más tenaces (los demás habrán desistido antes, tristemente).

Y para terminar tengo que dar las gracias a mis agazapados del Twitter, Marc Rubiño y Rodrigo Corral, por echarme una mano y compartir experiencias acerca de Sql CE (incluso siendo el día del Señor). Es un gustazo tener a gente así leyendo mis tonterías para ayudar. Otra vez gracias.

Un placer.

| Deja un comentario