Hace unos días una compañera de trabajo descubrió que no me gusta el café y su reacción fue decir “… que extraño!… un desarrollador al que no le gusta el café” y la verdad es que yo no lo consumo hace casi 20 años y bueno me entró la curiosidad de sondear en esta nuestra comunidad, los gustos que compartimos los desarrolladores, en esas largas horas de soledad entre tu código y uno mismo. Con la curiosidad del caso, aquí están las preguntas y respuestas más simples con opciones cerradas y comunes en mi país, sin ánimo de ofender o criticar ningún gusto en particular.
Cambiando mi navegador por defecto en Visual Studio
En reiteradas ocacione, varios amigos ya me preguntaron por esto y la verda es que en Internet uno no encuentra una respuesta del todo clara, por que hacer este cambio depende de la version de VS y del que tipo de proyecto ASP.NET que tengan, asi que antes que el conocimiento se pierda en las arenas del tiempo escribo este breve post.
La solucion general esta dada por este articulo: link, que muestra como hacer el cambio de navegador.
Para proyectos WebForms o MVC1 con VS2008
Ubicar el archivo default.aspx, hacer boton derecho sobre él y seleccionar la opcion "Browse with…”, el cuadro de dialogo que aparece contiene las opciones necesarias para hacer el cambio.
Para proyectos MVC2 con VS2008/2010
Bueno aqui las cosas se ponen confusas para mi, deberia existir una opcion para hacer este cambio, pero no la hay!, asi que tenemos que valernos de un pequeño truco, para hacerlo:
Agregar un archivo default.aspx o un archivo cualquiera.html al proyecto, una vez hecho esto podemos hacer boton derecho sobre el y tendremos la opcion “Browse with…”.
Personalmente prefiero agregar un archivo.html y excluirlo de la solucion si es que manejo algun control de versiones para que no todo mi equipo este preguntandose por que agregue ese archivo, que practicamente no tiene nada.
Para proyectos con VS2010
Alternativamente a lo que les mostre anteriormente, existe un addin disponible para descarga, que hace este proceso mucho mas sencillo. Este es el link.
Para aquellos que participamos activamente con sugerencias a Microsoft, tambien existe una pagina, donde se puede votar por incluir esta caracteristica, en futuras versiones, de tal manera que cambiar de navegador, no sea tan truculento.
Saludos
TDD con el patrón Test Data Builder
Desde hace algunos meses que vengo metido en todo esto del TDD y recientemente en el BDD, justamente la anterior semana que recien encontré un par de videos, de la invaluable comunidad ALT.NET Hispano, recomendables para BDD, uno de mi amigo Hernan García (Behaviour Driven Development) y otro el de Jorge Gamba (Haciendo BDD con MSpec), mientras veia este ultimo se menciona de pasada un patron llamado Test Data Builder, me entro la curiosidad y me puse a revisarlo, menuda sorpresa me lleve al descubrir que era justamente algo que llevaba haciendo de manera intuitiva hace ya unas semanas para organizar los constructores dentro de mis pruebas unitarias.
La documentacion de Test Data Builder menciona que es una alternativa a otro Patron usado frecuentemente, el Object Mother, que obviamente todos lo hemos usado aunque quiza no sabiamos su nombre formal, pero bueno basta de bla bla y mostremos código.
Ocurre que cuando estamos haciendo pruebas de nuestro codigo, en muchos casos nos encontramos ante la necesidad de crear objetos con diferentes estados (llamese estados a las multiples combinaciones de valores que pueden tener sus atributos), supongamos que dispongo de una clase ridiculamente simple llamada Person, como se muestra a continuacion:
public class Person
{
public string Name { get; set; }
public DateTime DateOfBirth { get; set; }
public string Address { get; set; }
public Person(string Name, string Address, DateTime DateOfBirth)
{
// TODO: Complete member initialization
this.Name = Name;
this.Address = Address;
this.DateOfBirth = DateOfBirth;
}
}
Esta clase puede ir creciendo en sus propiedades por lo que el constructor dejara de ser util pronto, pero lo dejo ahi para “dramatizar” la complejidad con la que nos enfrentaremos.
Aqui un par de pruebas tambien ridiculas pero que tienen por objetivo mostrar los patrones mencionados:
[TestMethod]
public void TestPersonInvalidAge()
{
Person enrique = PersonObjectMother.CreatePersonWithInvalidDate(new DateTime(1725, 1, 1));
var age = (DateTime.Now.Year - enrique.DateOfBirth.Year);
age = enrique.DateOfBirth > DateTime.Now.AddYears(-age) ? age - 1 : age;
Assert.IsTrue(age > 1 && age <= 130, "Age must be between 1 and 130, currently is " + age);
}
[TestMethod]
public void TestPersonInvalidName()
{
Person enrique = PersonObjectMother.CreatePersonWithInvalidName("123");
Assert.IsTrue(Regex.IsMatch(enrique.Name, "^[a-zA-Z'.]{1,40}$"), "The name should only contain letters");
}
Aqui la implementacion del Object Mother:
public static class PersonObjectMother
{
public static Person CreatePersonWithInvalidDate(DateTime dateTime)
{
Person p = new Person("Enrique", "Av. Gualberto Villaroel", dateTime);
return p;
}
internal static Person CreatePersonWithInvalidName(string name)
{
Person p = new Person(name, "Av. Gualberto Villaroel", DateTime.Now.AddYears(-25));
return p;
}
}
Si observamos el codigo de las pruebas puede parecer ordenado y con bastante sentido, sin embargo a medida que las pruebas van creciendo en complejidad, la clase Helper que no es otra cosa que un Factory, va saliendose de nuestras manos, porque se van creando metodos que luego son mas complicados de mantener asi como metodos “residuales” que pronto no seran usados. ¿La solucion? hay varias, yo veo fundamentalmente dos:
Una usar constructores anonimos, de la siguiente manera:
[TestMethod]
public void TestPersonInvalidAge()
{
//Person enrique = PersonObjectMother.CreatePersonWithInvalidDate(new DateTime(1725, 1, 1));
Person enrique = new Person
{
Address = "Av. Gualberto Villaroel",
Name = "Enrique",
DateOfBirth = new DateTime(1725, 1, 1)
};
var age = (DateTime.Now.Year - enrique.DateOfBirth.Year);
age = enrique.DateOfBirth > DateTime.Now.AddYears(-age) ? age - 1 : age;
Assert.IsTrue(age > 1 && age <= 130, "Age must be between 1 and 130, currently is " + age);
}
Parece tambien una buena idea, pero les aseguro que no lo es del todo, por que? Porque como observaran frecuentemente en la construccion de objetos, se necesita variar una o dos propiedades y dejar las restantes con valores “por defecto”, esto nos llevaria a duplicar bastante codigo, aqui quizá no es significativo pero pronto se convertiria tambien en un dolor de cabeza.
La otra solución, es usar Test Data Builder, una variacion personal que yo elegi, porque si ven las implementaciones mas formales, observaran que tambien se basan en metodos “fluent” para construir el objeto, pero aqui me valgo de los metodos anonimos para lograr un efecto mas “ordenado”.
[TestMethod]
public void TestPersonInvalidAge()
{
//Person enrique = PersonObjectMother.CreatePersonWithInvalidDate(new DateTime(1725, 1, 1));
//Person enrique = new Person
//{
// Address = "Av. Gualberto Villaroel",
// Name = "Enrique",
// DateOfBirth = new DateTime(1725, 1, 1)
//};
Person enrique = new PersonTestDataBuilder
{
DateOfBirth = new DateTime(1725, 1, 1)
}.Build();
var age = (DateTime.Now.Year - enrique.DateOfBirth.Year);
age = enrique.DateOfBirth > DateTime.Now.AddYears(-age) ? age - 1 : age;
Assert.IsTrue(age > 1 && age <= 130, "Age must be between 1 and 130, currently is " + age);
}
Como se observa, pareceria muy similar al uso de los metodos anonimos, solamente que aqui usamos un patron Factory, combinado con un constructor anonimo del Factory, esto nos permite enfocarnos solamente en la propiedad a la que queremos asignar el valor. Aqui el codigo del Test Data Builder:
public class PersonTestDataBuilder
{
public string Name { get; set; }
public DateTime DateOfBirth { get; set; }
public string Address { get; set; }
public PersonTestDataBuilder()
{
Name = "Enrique";
Address = "Av. Gualberto Villaroel";
DateOfBirth = new DateTime(1984, 8, 15);
}
public Person Build()
{
//return new Person(Name, Address, DateOfBirth);
return new Person
{
Address = this.Address,
DateOfBirth = this.DateOfBirth,
Name = this.Name
};
}
}
Espero que les sea útil.
Saludos
Perdiendo mis twitter posts?
Este post es realmente corto y probablemente no falte alguno que me diga que no tiene nada que ver con desarrollo, pero bueno quizá sí.
Desde hace un buen tiempo digamos unos 6 u 8 meses atrás me he vuelto un twitter user mas asiduo de lo que era antes y me vino la curiosidad (quien sabe porque?) de preguntarme que pasan con mis twitter posts, aunque realmente no hice nada para averiguarlo, hasta que me entro la necesidad y no solo la curiosidad, de obtener unos posts que hice hace algunos meses, porque deben saber que yo uso mi twitter más que como un lugar para jactarme de mis conocimientos o mostrárselos a la mayor cantidad de personas, como un lugar donde coloco todo lo que voy leyendo, investigando y curioseando diariamente y tener ese espacio como una especie de bitácora, en lo que se refiere fundamentalmente a mi gran pasion, el desarrollar software.
Pero menudos sustos me lleve al enterarme que primero, twitter solo almacena los 3200 últimos posts que hicieron (aqui mas informacion sobre este tema), afortunadamente yo voy solo por los 300, pero ya es el 10%, esto me comenzo a preocupar, sumado a que me puse a querer recuperar mis posts con la misma herramienta con la que los hago, actualmente uso una de las mejorcillas según yo, es twhirl, lo sé lo sé, está construida con Adobe Air, pero Uds. me recomendaran otra que quizá esté basada en .NET, aunque debo decir que también pase unas buenas horas buscando una para postear y la mejor es twhirl, insisto para mí; bueno me estoy saliendo del tema, que es que definitivamente no podía encontrar mis antiguos posts en Twitter.
Buscando me encontré con este artículo que hizo crecer enormemente mis temores de haber perdido definitivamente mis post antiguos de twitter, por más que en la página oficial digan que puedo recuperar los últimos 3200, no sería la primera vez que algún fabricante promete que su producto hace algo, cuando en realidad no lo hace. En el artículo se menciona una expiración de los posts, nuevamente un susto y no porque el post que buscaba era lo más importante del mundo, sino porque todos los post que hice sumados representan meses de anotar metódicamente cosas importantes. Pero como verán en ese post aparte de mencionar el problema, muestra 10 posibles soluciones para respaldar nuestros post de twitter. Luego de probar todas ellas debo indicar que recomiendo las siguientes dos:
The archivist, que no es nada más ni nada menos que una aplicación WinForms, con un instalador ClickOnce, en si la herramienta recupera, si bien no todos sus posts, la mayoria un gran plus que tiene es la posibilidad de exportacion a excel y el analisis de los datos recuperados de Twitter, por usuario.
Tweetake, que es una aplicación twitter web, esta es la que se lleva la flor, porque efectivamente recupero la totalidad de mis posts, y no solo permite recuperarlos, sino incluso realizar backups de toda la configuración de twitter, favoritos, seguidores, amigos, etc. y exportar todo a un archivo delimitado por comas, que obviamente puede ser abierto por Excel.
Como supondrán correctamente, seguiré haciendo mis posts en Twitter, esperando que un día ellos implementen la recuperación de todos mis posts, como lo prometen, sin ninguna restricción, mientras seguiré usando Tweetake y secundariamente The Archivist para respaldar regularmente mi bitácora en la web.
Saludos
Transformando mi código MVC2 gracias jQuery, JSON y Ajax
Por varios años, mi experiencia en desarrollo web, dentro de .NET, ha estado atiborrada de frases y términos como “postback”, “ciclo de eventos”,”viewstate”, etc, etc. Incluso algunas de mis certificaciones las obtuve con exámenes de lo que ahora se conoce como ASP.NET WebForms. Recientemente he decidido encarar un nuevo proyecto, con nuevas tecnologías, entre ellas Windows Identify Foundation (en algún momento escribiré algo acerca de esto) y ASP.NET MVC2. Esta última me ha remontado al pasado, al recordarme mi relación con PHP, pero esta también es otra historia.
La necesidad de pensar de otra manera evitando la simplicidad “engañosa” que ofrece el postback, me ha llevado a decidir “ajaxificar” toda o la mayor parte mi relación con MVC2, en este camino me he encontrado con algunos problemillas, como el siguiente:
- Necesito una forma de que un Action Controller, devuelva una lista de datos, para esto he pensado retornar un JsonResult, que será tomado por el browser.
- Una vez el browser reciba este conjunto de datos JSON, los procesara de alguna manera, que no es relevante mencionarla ahora, este procesamiento se lo hara vía javascript.
- Luego que termine este procesamiento el conjunto de datos JSON transformado, debe ser retornado a otro Action Controller, que finalmente lo recibirá, serializado y listo para ser guardado en una base de datos.
Los pasos mencionados anteriormente son una simplificación conveniente de todo lo que hace mi aplicación, pero se enfocan en los problemas que encontré al trabajar con ajax y json combinándolo con MVC2.
Los primeros dos pasos, no significaron un gran desafío, en lo absoluto:
Para retornar desde un Action Controller un resultado JSON solo se debe usar un código similar al siguiente (ninguna cosa del otro mundo):
Invocar este Action Controller, desde javascript, tampoco representa un gran desafío, al menos no con jQuery:
Obsérvese en el anterior código, lo importante que es que el segundo parámetro del método $.post, tenga el mismo nombre que el parámetro del action controller, en este caso hablamos del parámetro “packageKey”.
Hasta aquí ningún problema, este apareció cuando quise hacer efectivo el tercer paso, es decir pasar el JSON manipulado, siguiendo el ejemplo lo que está contenido en _selectedUsers, a un otro action controller. Recuerden que _selectedUsers fue retornado, por el action controller GetSelectedUsers.
Intente muchas cosas, bastantes para ser exactos, muchas recomendaciones, probé código y lo que me funciono mejor fue implementar un custom model binder como un atributo, llamado JsonBindderAttribute, el código es el siguiente:
Observe como estoy utilizando el JsonBinderAttribute, en la declaración del parámetro, que intencionalmente he llamado xx, para denotar su singularidad. Este artículo no estaria completo sin el código de este atributo que es lo que más me ha costado encontrar y probar, pues reitero parece que muy pocos estan usando esta técnica de pasar JSON a un Action Controller. Sin mas palabras aquí el código del atributo:
Parecería que lo tenemos todo, sin embargo falta lo que muchos autores se han olvidado mencionar, quizá la cereza de este articulo 🙂 y eso es….. ¿Cómo se invoca al action controller GetAvailableUsers? Algunos pueden precipitarse a responder, pero mejor les paso el código:
Aquí podemos apreciar la sutil diferencia con la invocación del Action Controller GetSelectedUsers, el parámetro xx que recibe el List<SomeDto> es serializado a un string JSON con la funcion stringify de la librería JSON2, que puede ser descargada aquí. Sin esta instrucción se recibe permanentemente la lista en null o con elementos vacíos.
Esta técnica de usar JSON entre llamadas, bien podría ser utilizada como una técnica de mantenimiento de estado, que es lo que precisamente hago yo, es decir mantengo el estado entre llamadas a los Action Controller dentro del contenedor JSON, funciona a la perfección.
Espero que esto le pueda servir a alguien, tanto como me sirvió a mí.
Un saludo!
Entity Framework 4.0 en una Arquitectura N-Tier
Como un “enamorado” de EF4, aquí les paso una recopilación de muchos enlaces de importancia vital, para aquellos que emprendan el camino de usar EF en una arquitectura N-Tier.
Artículos de MSDN Magazine:
The Entity Framework In Layered Architectures
http://msdn.microsoft.com/en-us/magazine/cc700340.aspx
Anti-Patterns To Avoid In N-Tier Applications
http://msdn.microsoft.com/en-us/magazine/dd882522.aspx
Entity Framework: N-Tier Application Patterns
http://msdn.microsoft.com/en-us/magazine/ee321569.aspx
Building N-Tier Apps with EF4
http://msdn.microsoft.com/en-us/magazine/ee335715.aspx
Entity Framework 4.0 and WCF Data Services 4.0 in Visual Studio 2010
http://msdn.microsoft.com/en-us/magazine/ee336128.aspx
Blogs de Entity Framework Design:
Self-Tracking Entities in the Entity Framework
http://blogs.msdn.com/b/efdesign/archive/2009/03/24/self-tracking-entities-in-the-entity-framework.aspx
N-Tier Improvements for Entity Framework
http://blogs.msdn.com/b/efdesign/archive/2008/11/20/n-tier-improvements-for-entity-framework.aspx
Código de ejemplos:
Building N-Tier Apps with EF4
http://code.msdn.microsoft.com/mag200911EF4
Entity Framework 4.0 and WCF Data Services 4.0 in Visual Studio 2010
http://code.msdn.microsoft.com/mag201004VSData
Más blogs útiles:
Updating data using Entity Framework in N-Tier and N-Layer Applications (short lived EF contexts) – (Part 1) (Cesar de la Torre)
http://blogs.msdn.com/b/cesardelatorre/archive/2008/09/04/updating-data-using-entity-framework-in-n-tier-and-n-layer-applications-short-lived-ef-contexts.aspx
Optimistic Concurrency Updates using Entity Framework in N-Tier and N-Layer Applications (Part 2) (Cesar de la Torre)
http://blogs.msdn.com/b/cesardelatorre/archive/2008/09/05/optimistic-concurrency-updates-using-entity-framework-in-n-tier-and-n-layer-applications-part-2.aspx
N-Tier Methods in Entity Framework 4 – Use with Care (Julie Lerman)
http://thedatafarm.com/blog/data-access/n-tier-methods-in-entity-framework-4-ndash-use-with-care/
POCO sobre WCF?
Aquí también aprovecho para plantear una eterna discusión, los POCO deben o no deben viajar entre la capa de servicios y la capa de presentación?
Desde mi punto de vista por simplicidad de gestión sí, pero desde el punto de vista de “limpieza” de diseño no, lo que debería viajar entre las capas de servicio y presentación deben ser siempre los famosos DTOs o como algunos conocen “Value Objects”.
Sin embargo aquí les dejo a Jamie Phillips, que en una entrada muy explicativa nos muestra como pasar los POCO por la capa de servicios.
POCO with EF 4.0 and WCF 4.0
http://devblog.petrellyn.com/?p=278
La decisión siempre será tuya.
Saludos
MVC + jqGrid = Dolores de cabeza
El titulo refleja lo que estuve padeciendo estos días con MVC y jqGrid y más que una queja es un título para atraer lectores :), porque si bien la combinación me produjo un dolor de cabeza que un anti-migrañas desapareció, en realidad me he estado divirtiendo más que nunca con lo que estoy haciendo J. Pero aquí les presento el problema al que me enfrente:
Como han debido explorar por la web existen muchos y variados artículos que muestran el uso de jqGrid junto a ASP.NET MVC, todos ellos hablan de lo simple que puede ser combinarlos para lograr un grid de prestaciones profesionales en “minutos”, todo ello tiene algo de verdad, aquí les muestro un script (demo.js) que contiene el código que prepara un jqGrid.
Observaran en la captura que he marcado un parámetro llamado url, este parámetro apunta a un “Action Method” de un Controller, que es el responsable de poblar el grid.
El método es como el siguiente:
Como poblaran el grid ya cuestión de cada uno, por cierto este no es un post para cubrir como poblar un jqGrid, para eso saint-google puede ayudarles.
Hasta aquí todo normal, pulsamos F5 en un mundo de desarrollo ideal, el grid se llena de datos.
En mi navegador se puede observar la uri que contiene y que efectivamente corresponde al servidor web de desarrollo que se levanta con Visual Studio.
Hasta aquí todo bien, todas las promesas de un grid con prácticamente con poco esfuerzo casi se cumplen y digo CASI porque pasando al mundo real, es decir llevando esta aplicación a un servidor de pruebas que está ubicado en un host como ser: http://testserver/reportapp/, es donde los problemas comienzan.
Inexplicablemente cuando se inicia la aplicación en el servidor de testeo, el grid no se puebla de datos, aparece totalmente VACIO!!!!, vuelvo a mi máquina de desarrollo y todo funciona de mil maravillas pero en el servidor NO! ¿Qué ocurrió?
Haciendo uso del buen Firebug (a mis amigos que ya me conocen…..mejor no digo nada), logro descubrir el error. Sucede que en mi máquina de desarrollo todo va de maravillas por que la propiedad url del grid, que les muestro nuevamente:
Forma una url completa como la siguiente: http://localhost:34953/Report/FillSatisfactionData, url totalmente valida, PERO, cuando examino la url que se forma en el servidor de testeo es http://testserver/Report/FillSatisfactionData, a los que me están siguiendo con detenimiento en la explicación, se darán cuenta que algo falta en la URL, el link que se ha formado ha omitido el directorio virtual!!!!!
Este “problema” es el que me tuvo entretenido unos minutos y también buscando una solución en saint-google, pero como que parece que nadie hubiera tenido el mismo problema, quizá estoy cometiendo un error de omisión en alguna parte y tenía que dar solución a este inconveniente así que a continuación les muestro como los resolví.
He construido un jscript similar al siguiente:
<script type="text/javascript">
$.currentPath = function (url) { { return ‘<%= Request.Url.AbsoluteUri%>’ + url; }; }
$.domain = function (url) {
{
return ‘<%= string.Format("{0}://{1}{2}{3}", Request.Url.Scheme, Request.Url.Host, Request.Url.Port == 80 ? string.Empty : ":" + Request.Url.Port, Request.ApplicationPath) %>’ + url;
};
}
</script>
Este código está dentro del Site.master y como podrán observar tiene 2 funciones, una $.currentPath y la otra $.domain ambas destinadas a devolver la url absoluta “completa” de nuestro servidor, la más útil para resolver el problema es la última función, que sea cual sea el nivel de anidamiento de un directorio virtual nos devolverá o formara correctamente la url.
El código resultante de nuestro .js que contiene la inicialización del jqGrid, se convierte en lo siguiente:
Espero que a alguien le sirva esta pequeña experiencia y si Uds. tienen una mejor solución o una corrección a esta, pues bienvenida.
Un abrazo.
Entity Framework 4, Model-First, POCO, T4, Code-Only
Complementando el post de Luis Franco (http://geeks.ms/blogs/lfranco/archive/2010/01/12/mejoras-en-entity-framework-4.aspx), referido a las mejoras que trae EF4, hago mi aporte con un poco de mis experiencias y puedo decir que existen varias formas de usar EF4, entre ellas:
Primera – Tradicional
La manera tradicional y que proviene de EF1, DataBase-First, donde se parte de una base de datos existente, a partir de la cual se crean las entidades, modelo sostenible desde mi punto de vista, para aplicaciones pequeñas.
Con la aparición de EF4 (debería haber sido EF2, pero vamos!) y obviamente a raíz de pedidos airados de la comunidad, se introduce el desarrollo Model-First, donde a partir de un modelado de entidades se genera una base de datos, esta forma de usar EF es la más interesante, incluso si queremos verlo así va acorde con iniciativas como MDA, pero mas allá de esto, quizá lo interesante que trae EF, es que se puede aplicar Model-First, de variadas formas, he aquí las que yo he explorado.
Segunda – Model First Tradicional
Manera "nativa", esta consiste en crear un modelo .edmx vacio, he ir agregando las diversas entidades, sus atributos y sus relaciones y en algún momento del tiempo escoger una opción dentro del diseñador, que se llama "Generate Database from Model…", esto producirá una base de datos "compatible" con nuestro modelo, en realidad producirá un script (.sql) que luego puede ser ejecutado y generar la base de datos. http://blogs.microsoft.co.il/blogs/gilf/archive/2009/05/23/model-first-in-entity-framework-4.aspx
http://channel9.msdn.com/posts/Eric+Nelson/Entity-Framework-4-Part-1-Simple-Model-First/
Tercera – Model First con POCO y T4
La siguiente manera de usar Model-First, viene del descontento, de tener entidades que son dependientes de Entity Framework, esto ocurre incluso al usar la anterior opción, donde las entidades que se generan aun heredan de EntityObject una clase de EntityFramework, generando código similar al siguiente:
Y aunque han surgido otros “artificios” para tratar de eliminar esas dependencias en EF1, tales como IPOCO o IEntityObject, todas terminan introduciendo indirectamente una dependencia hacia Entity Framework.
En este sentido Microsoft introduce en EF la posibilidad de usar un concepto ya “antiguo” en otras plataformas, el concepto de POCO (Plain-Old-CLR-Object) que propugna tener objetos simples sin dependencias como las anteriores opciones, que en definitiva se conviertan en las entidades del modelo y a partir de estas clases se generara la base de datos.
Para lograr este propósito se vale de las plantillas de generación de código T4 (Text Templating Transformation Toolkit), para esto se utiliza una plantilla que aun no sé si esta en beta o no, no anda muy claro en VisualStudioGallery (http://visualstudiogallery.msdn.microsoft.com/en-us/23df0450-5677-4926-96cc-173d02752313) Sin embargo esta opción de usar Model-First considera la posibilidad de reemplazar el generador por defecto por uno personalizado, que será el responsable de generar las clases POCO, personalmente esta opción me gusta, es bastante simple utilizarla, pero me trajo problemas cuando quiero hacer un uso semi-avanzado, por ejemplo usar enumeradores, para esto he tenido que personalizar el template T4 .tt, para que cumpla mis requerimientos. Esta opción se puede habilitar seleccionando la opción “Add code generation item….”
Esto permitirá seleccionar la plantilla que descargo del enlace anterior y obviamente que ya instalo.
Esto cambiara totalmente la forma en la que se generan las clases y eliminara las dependencias de estas clases de EntityFramework, en los siguientes enlaces podrán encontrar una guía paso a paso de cómo aprovechar esta forma de Model-First.
Cuarta – Model First Limpio con Doble Trabajo
La cuarta forma de usar EF y la tercera de usar el Model-First, está un poco “escondida” a simple vista, la considero probablemente la más “limpia” de las formas de usar Model-First, sin embargo requiere más trabajo, esta consiste en crear dos librerías de clases una para las entidades y otra para el mapeo, la librería de las clases POCO, contendrá todas las clases TOTALMENTE planas, no se usa ningún generador, no se usa ninguna referencia hacia EntityFramework y el diseño de las clases puede hacerse usando un ClassDiagram de VS, luego en la librería de mapeo se agrega un modelo edmx, se lo libera de generar las clases de manera tradicional, eliminando el contenido de la propiedad CustomTool, como se muestra en la siguiente captura:
Se procede a referenciar a la librería de clases POCO y aquí viene el doble trabajo, hay que volver a modelar las mismas clases que se modelaron en la librería POCO, en el modelador EDMX, las entidades que se modelen en el modelador EDMX tienen que tener, el mismo nombre de clase, las mismas propiedades y sus mismos nombres, de lo contrario no funcionara, haciendo este doble trabajo de modelación, se logra una forma de Model-First mas limpia para aquellos que no gusten de los generadores, aquí también les dejo unos enlaces, lean el primero y luego váyanse a los demás, si analizan lo que se hace en el segundo enlace observaran que aunque no se hace exactamente lo que digo, bajándose el ejemplo podrán probar mas rápidamente esta característica
http://www.code-magazine.com/articleprint.aspx?quickid=0909081&printmode=true
Quinta – Model First con Code Only
La ultima forma de usar EF4 y fundamentalmente Model-First, no está totalmente evolucionada, como dicen sus autores, la llaman Code-Only y es bastante similar en concepto a NHFluent o Fluent NHibernate, es una forma que combina la creación del modelo con clases POCO y la definición de restricciones y relaciones por código, es una alternativa bastante poderosa si queremos evitar incluso los edmx, pero habrá que esperar algún tiempo antes de usarla en su totalidad. Aquí les dejo enlaces para que puedan explorar esta alternativa:
http://blogs.msdn.com/b/efdesign/archive/2009/10/12/code-only-further-enhancements.aspx
http://blogs.msdn.com/b/efdesign/archive/2009/08/03/code-only-enhancements.aspx
Principales Observaciones a EF4
- Hasta el momento no he encontrado un mecanismo para preservar mis datos, en la base de datos, durante los ciclos de modificación del modelo y generación de la base de datos, en Model-First, es decir cada vez que genero una base de datos pierdo la información que tenia almacenada, bueno creo que este "inconveniente" no solo afecta a EF sino también a otros ORM como NHibernate y podemos decir que nace a partir de lo complicado que sería restaurar datos en una tabla, cuando esta ha cambiado drásticamente, pero me gustaría ver algunas sugerencias o soluciones a este inconveniente.
- Los enumeradores, benditos enumeradores!!!, deberían ser soportados en EF, se que se ha prometido en las siguientes actualizaciones hacerlo, pero la verdad que no sé cuándo será, mientras tanto hay que usar trucos como estos (http://blogs.msdn.com/b/alexj/archive/2009/06/05/tip-23-how-to-fake-enums-in-ef-4.aspx, http://devtalk.dk/CommentView,guid,d5dccc2a-5723-49b4-97d1-bf759b7f592d.aspx), para saltarnos este otro inconveniente, hasta que nativamente tengamos soporte a enumeradores, creo yo como tipos complejos, que opinan Uds.?
- El soporte completo para los GUIDs como llaves primarias es otro aspecto que observo ausente en EF4, aun hay que hacer “cosas” extrañas para poder tener una generación automática de Guids, espero que en la siguiente versión se tenga algo nativo
http://leedumond.com/blog/using-a-guid-as-an-entitykey-in-entity-framework-4/
Espero que les sirva este conjunto de experiencias, un abrazo
Ecuaciones del aprendizaje
Hoy estuve “meditando” sobre las diferentes formas de aprendizaje, que he visto en nuestra profesión de desarrolladores y bueno principalmente en mi país, quizá alguno quiere compartir opiniones adicionales?
aprendizaje_efectivo=lectura_teoria+ejemplo_practico+re_lectura_teoria;
El aprendizaje efectivo solo lo hacen los fuertes de voluntad y carácter, una vez leída la teoría, muy pocos quieren o desean volver a leerla. Sin embargo los que lo practican, tienen asegurado un retorno de la “inversión” con creces.
aprendizaje_empirico=ejemplo_practico;
Este aprendizaje es propio de los que no tienen una formación “formal” han aprendido las “artes” viendo y aplicando. Personalmente le atribuyo a este aprendizaje, las grandes deficiencias de los profesionales junior.
aprendizaje ligero=lectura_teoria+ejemplo_practico;
Este es el aprendizaje común, con el que muchos se satisfacen porque lo consideran más que suficiente, probablemente suficiente para entablar una conversación, pero no para enseñar por ejemplo.
aprendizaje_teorico=lectura_teoria+re_lectura_teoria;
Definitivamente el aprendizaje que no veremos en una empresa que produce “algo”, y bueno yo he visto este aprendizaje lamentablemente en varios docentes de las universidades de mi país. Probablemente un aprendizaje valido pero no útil para enseñar.
En estas “ecuaciones” de aprendizaje, quizá faltan mas variables o quizá hay mas tipos de aprendizaje, veamos….
Secuestraron mi puerto 80!
Hoy me ocurrieron varios errores misteriosos dentro del laburo, uno de ellos, al iniciar mi computadora con Windows 7, no se levantaba el servicio de IIS, dándome el siguiente error
The WWW Service did not register the URL prefix http://*:80/ for my site
Según todos los datos, el Puerto 80 estaba secuestrado por “alguien” más, lo cual no dejaba que se inicie correctamente el IIS, Estuve como 30 minutos desperdiciando mi tiempo en encontrar una solución porque no había un claro indicador de “quien” era el que se había apropiado de mi puerto 80, por mi mente paso incluso el deseo de reinstalar el IIS pero tenía demasiadas configuraciones que no podían ser restauradas en un tiempo razonable.
Hasta que me tope con un comentario de una persona que me pregunto si usaba Skype y válgame….. Eso era! Skype se había apropiado de una manera extraña de mi puerto 80, lo único que hice fue desmarcar la opción como se muestra a continuación y listo.
Espero que esto le sea de ayuda a alguien más para que no desperdicie 30 valiosos minutos en una búsqueda en internet.
Saludos