Mes: agosto 2010

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

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.