Radarc, el “Tanque” de Visual Studio

Seguro que todos tenéis en algún rincón de vuestra mente la gran escena de Triniti en Matrix: “Tanque, necesito un programa de pilotaje para un helicóptero B-212, ¡Date Prisa!”

¿Os imagináis que algo así fuese posible? Pues para sorpresa de todos, es posible gracias a Radarc y los chicos de Icinetic que lo hacen posible, por ahora en nuestro mundo del bit&byte.

RadarC es un generador de código para .NET muy sencillo y realmente útil. Plantándonos unas reglas de diseño arquitecturales sólidas con las que cimentar nuestros proyectos. Y para muestra un botón, vamos a crear una pequeña aplicación en para MVC con RadarC, pero para ello tenemos que prepararnos el sistema.

Sólo tenemos que ir a la web de Radarc y seguir sus instrucciones de instalación, son muy sencillas. Acto seguido nos descargamos la Formula MVC, hay que hacer el proceso de compra pero es totalmente gratuito ;).

¿Qué es una Formula?

Una fórmula es una arquitectura empaquetada y configurada por defecto con todo lo necesario para centrarnos en nuestro negocio y preocuparnos de hacer lo que realmente aporta valor a nuestro proyecto. En el ejemplo que vamos a ha realizar se trata de una aplicación para ASP .NET MVC y la Formula MVC nos va a permitir crearla de forma muy sencilla y ordenada como veremos.

Manos al teclado.

Una vez preparado nuestro entorno, sólo tenemos que abrir Visual Studio 2010 e irnos al menú “Nuevo Proyecto”. Veremos que ha aparecido una nueva plantilla llamada Radarc:

Cuando hagamos clic en “OK” nos preguntará qué fórmula queremos usar, en nuestro caso seleccionamos “MVC Formula”:

En este momento nos pedirá cierta información que necesita para poder acceder a la base de datos, namespace por defecto, y el estilo básico (hemos seleccionado el Green) necesario para crear la estructura básica de toda la solución:

Una vez hagamos clic en “Finish” Radarc comenzará a crear la arquitectura básica y necesaria para un proyecto MVC:

Ahora podemos empezar a modelar nuestro negocio de forma muy sencilla. Fijaos que directamente nos deja abierto el diseñador de modelos de nuestro Entity Data Model para comenzar a modelar nuestro negocio. De esta manera vamos a añadir cuatro Entidades a este modelo directamente:

Las cuatro entidades y las propiedades que necesitamos son :

• Product:
  • Description (string)
  • UnitPrice (decimal)
• Order Detail:
  • Ammount (Int16)
  • Discount (Single)
• Order:
  • OrderDate (DateTime)
  • DeliveryDate (DateTime)
  • ShippingAddress (String)
• Customer:
  • CustomerCode (Int16)
  • CompanyName (String)
  • ContactName(String)

Así quedaría nuestro modelo:

Ahora toca establecer las relaciones entre nuestras entidades, tenemos que establecer las relaciones de

•  Un Product está en varias OrderDetails
• Una Order tiene varias OrderDetails
• Un Customer tiene 0 o varias Order.

Guardamos los cambios y ejecutamos la aplicación, aseguraros de que el proyecto por defecto es el  proyecto MVC, ya que si no lo hacéis, se puede establecer como proyecto de inicio otro y os dirá que no existe un punto de entrada.

Cuando ejecutamos la aplicación, RadarC comenzará a generar todo el código fuente, creando las entidades, test, vistas,  servicios que exponen la lógica de negocio para ser consumida desde otros clientes, View Models y lanzará la aplicación lista para ejecutar:

Y ya, a partir de aquí tenemos una aplicación MVC lista para poder meterle datos y todo. Es una app totalmente funcional, id probando a añadir clientes, productos y todo lo demás.

Fijaos que incluso la aplicación ya está preparada para múltiples idiomas, si abrimos el Global.asax veremos este código y en el directorio App_GlobalResources tendremos los diferentes archivos de recursos:

Resumen

Los chicos de Icinetic han hecho un excelente trabajo con Radarc, un trabajo realmente envidiable.

Me ha sido posible acceder a una beta privada que tienen lista ya para VS 2012 y Windows 8 y el funcionamiento es exactamente igual.

Juan María Laó Ramos

HttpAntiForgeryException en ASP.NET MVC

Hola a todos, gracias a Jose María Aguilar hoy he resuelto un pequeño problema con ASP.NET MVC de esos de los que te pegas dos días loco.

La cosa se puede reproducir muy fácilmente creando un nuevo proyecto MVC tal cual nos lo genera Visual Studio 2012:

                 

Si la ejecutamos directamente  nos aparecerá la web por defecto totalmente funcionando. Ahora, vamos a registrar un nuevo usuario, y nos mantendremos logados.

Para reproducir el error que me ha vuelto loco sólo tenemos que deslogarnos, hacer clic en login y logarnos. Una vez logamos le damos al botón del navegador para que vaya a la página anterior, y veremos que se mantiene el nombre de nuestro usuario:

Y la gracia está en que si escribimos nuestro password y nos logamos obtenemos un bonito error:

Server Error in ‘/’ Application.

---

The provided anti-forgery token was meant for user “”, but the current user is “juanma”.

             Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Web.Mvc.HttpAntiForgeryException: The provided anti-forgery token was meant for user “”, but the current user is “juanma”.
Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[HttpAntiForgeryException (0x80004005): The provided anti-forgery token was meant for user "", but the current user is "juanma".] System.Web.Helpers.AntiXsrf.TokenValidator.ValidateTokens(HttpContextBase httpContext, IIdentity identity, AntiForgeryToken sessionToken, AntiForgeryToken fieldToken) +234369 System.Web.Helpers.AntiXsrf.AntiForgeryWorker.Validate(HttpContextBase httpContext) +71 System.Web.Helpers.AntiForgery.Validate() +80 System.Web.Mvc.ValidateAntiForgeryTokenAttribute.OnAuthorization(AuthorizationContext filterContext) +22 System.Web.Mvc.ControllerActionInvoker.InvokeAuthorizationFilters(ControllerContext controllerContext, IList`1 filters, ActionDescriptor actionDescriptor) +96 System.Web.Mvc.Async.<>c__DisplayClass25.<BeginInvokeAction>b__1e(AsyncCallback asyncCallback, Object asyncState) +446 System.Web.Mvc.Async.WrappedAsyncResult`1.Begin(AsyncCallback callback, Object state, Int32 timeout) +130 System.Web.Mvc.Async.AsyncControllerActionInvoker.BeginInvokeAction(ControllerContext controllerContext, String actionName, AsyncCallback callback, Object state) +302 System.Web.Mvc.<>c__DisplayClass1d.<BeginExecuteCore>b__17(AsyncCallback asyncCallback, Object asyncState) +30 System.Web.Mvc.Async.WrappedAsyncResult`1.Begin(AsyncCallback callback, Object state, Int32 timeout) +130 System.Web.Mvc.Controller.BeginExecuteCore(AsyncCallback callback, Object state) +382 System.Web.Mvc.Async.WrappedAsyncResult`1.Begin(AsyncCallback callback, Object state, Int32 timeout) +130 System.Web.Mvc.Controller.BeginExecute(RequestContext requestContext, AsyncCallback callback, Object state) +317 System.Web.Mvc.Controller.System.Web.Mvc.Async.IAsyncController.BeginExecute(RequestContext requestContext, AsyncCallback callback, Object state) +15 System.Web.Mvc.<>c__DisplayClass8.<BeginProcessRequest>b__2(AsyncCallback asyncCallback, Object asyncState) +71 System.Web.Mvc.Async.WrappedAsyncResult`1.Begin(AsyncCallback callback, Object state, Int32 timeout) +130 System.Web.Mvc.MvcHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object state) +249 System.Web.Mvc.MvcHandler.BeginProcessRequest(HttpContext httpContext, AsyncCallback callback, Object state) +50 System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) +16 System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +301 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +155

---

Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.17929            

 Simplemente precioso.

Es un problema de la caché,  y es que el forgery-token se guarda información relativa a la sesión que hemos iniciado con el servidor, entre ellas el usuario logado. Al ser una petición GET el navegador intenta obtener ese token de la caché, pero el servidor se da cuenta de que ese token ha sido cargado de la caché del navegador y no ha sido generada en la petición actual, por lo que, para evitar ataques de Cross-Site Request Forgery, nuestro servidor (que es muy listo) dice: eh!, ¿a donde te crees que vas?

La solución para que el navegador no nos cargue ese token (y otras cosas) en las peticiones GET que hagamos cuando queremos logarnos es indicarlo en nuestro método de login. En un proyecto MVC4 por defecto, ese método está en la clase AccountController.cs

 [AllowAnonymous]
 public ActionResult Login(string returnUrl)
 {
    ViewBag.ReturnUrl = returnUrl;
    return View();
 }

¿Cómo se lo indicamos?, añadiendo el atributo OutputCache de la siguiente manera:

 [AllowAnonymous]
 [OutputCache(NoStore = true, Duration = 0)]
 public ActionResult Login(string returnUrl)
 {
    ViewBag.ReturnUrl = returnUrl;
    return View();
 }

Si recompilamos y ejecutamos repitiendo el proceso de logarnos, navegar a la página anterior con el botón del navegador y haciendo clic en Login, ya no nos aparece el nombre de nuestro usuario anterior, sino que aparece vacío y podemos logarnos sin ningún problema y sin excepciones

Espero que os haya gustado y de nuevo tengo que darle las gracias a Jose María Aguilar por su ayuda 🙂

El foreach puede causar problemas de memoria

Después de tener algo de tiempo he ido a mi lista de cosas por leer y me quedado a cuadros cuando lo he leído.

http://blogs.msdn.com/b/etayrien/archive/2007/03/17/foreach-garbage-and-the-clr-profiler.aspx

Sí es un enlace del 2007, lo sé, imaginaos la de cosas que tengo en esa lista :P.

En resumen, imaginemos este código:

class Program
{
    class GameEntity
    {
        public void Update()
        {
        }
    }

<pre><code>static GameEntity[] entities = new GameEntity[100];
static Program()
{
    for (int i = 0; i &amp;lt; entities.Length; i++)
    {
        entities[i] = new GameEntity();
    }
}

static void Main(string[] args)
{
    byte[] byteArray = new byte[1];
    for (int i = 0; i &amp;lt; entities.Length; i++)
    {
        entities[i].Update();
    }
}
</code></pre>

}

En el post original, después de pasar el CLR Profiler no se hace reserva de memoria para un enumerador para poder recorrer la colección, algo lógico. Después, para ver la diferencia con el foreach sustituye el código del for por este otro:

static void Main(string[] args)
{
   byte[] byteArray = new byte[1];
   foreach (GameEntity e in entities)
   {
      e.Update();
   }
}

En el caso del foreach se reserva memoria para un enumerador necesario para recorrer el foreach.

Y todo va perfecto, sin embargo, hay un escenario en el que se pueden producir fugas de memoria:

const int NumEntities = 100;

static List list = new List();
static Program()
{
   for (int i = 0; i < NumEntities; i++)
   {
         list.Add(new GameEntity());
     }
}
static void Main(string[] args)
 {
     UpdateIEnumerable(list);
 }
private static void UpdateIEnumerable(IEnumerable enumerable)
 {
     foreach (GameEntity e in enumerable)
     {
         e.Update();
     }
 }

En este caso sí se producen fugas de memoria. Y es que aunque estemos haciendo un foreach en una lista, cuando se le hace un casting a una interfaz, al tipo valor del enumerador se le hace un box, y se coloca en el heap.

La conclusión:

• Cuando hacemos un foreach sobre un Collection<T> se reserva memoria para un enumerador.
• Cuando hacemos un foreach sobre la mayoría de las colecciones, como arrays, listas, colas, listas enlazadas y otras:
  • Si se usan explícitamente, NO se reserva memoria para un enumerador.
  • Si se usan a través de interfaces, se reserva memoria para un enumerador.

Así que si el consumo de memoria es algo crítico en vuestra aplicación o juego , nunca, nunca, uséis interfaces para recorrer una colección.

 

[Update: Gracias a Bernardo por el comentario]

El problema aparece cuando el “foreach” recorre la colección como si fuera un “IEnumerable”. En este caso se utiliza la implementación explícita de “GetEnumerator()” y se realiza “boxing” del “struct” para devolver un tipo “IEnumerator”.

El “boxing” es una operación costosa y puede llegar a consumir mucha memoria.

P.D: el método “GetEnumerator()” de  “Collection” no devuelve un “struct”. Es de las pocas colecciones que son una excepción.

Espero que os haya gustado tanto como a mi. 🙂

Juan María Laó Ramos.