While I was dealing with some potential vulnerability issue affecting to some of "my" MVC 5.0 application in .Net Framework 4.5 and coming from a wrong management of user roles, it turns out that I didn't remember clearly how role management was related to User principal or even, where roles came from in order to IsInRole method were able to work properly to check roles for users. So, let me add this post as a reminder to clarify and shed light on this.

In a nutshell, the provider model is a design pattern largely used by Microsoft components for allowing an application to make use and choose from multiple implementations of a given contract based on the settings of a configuration file. So, for instance, management of user membership or roles are usually carried out by means of classes based on this pattern (see MemberShipProvider or RoleProvider classes). This way, the application can choose the default provider for dealing with membership or roles, add or remove providers, etc. in a declarative way. It brings a lot of benefits for developers as they can plug new components easily without refactoring code.

This article explains how to create a simple Multi-Language ASP.NET MVC 5 Web application. The application will be able to deal with English (United States), Spanish and French languages. English will be the default language. Of course, it will be very easy to extend the solution for including new languages.

Article available only in Spanish

Como usted ya puede suponer si leyó los artículos anteriores de esta serie, la principal desventaja del uso de ORMs es que uno tiende a desentenderse y, en consecuencia, desconocer la magia generada por el ORM para consultar y persistir datos en el RDBMS, dando por hecho que éste no sólo será capaz de cumplir con las acciones requeridas sino de hacerlo de forma eficiente. Esto es un grave error en aplicaciones complejas en las que el rendimiento es un factor clave. Sólo supervisando y entendiendo bien esta magia que hay por debajo de los ORMs nos permitirá optimizar el rendimiento de nuestras aplicaciones.

Article available only in Spanish

La principal ventaja que nos aporta el uso de un ORM es la reducción de código a escribir en nuestra aplicación en comparación con las técnicas tradicionales de acceso a datos sobre RDBMS. La principal desventaja derivada del alto nivel de abstracción generado entre el modelo de entidades de nuestra aplicación y el RDBMS subyacente es que se tiende a “pasar por alto” toda la “magia” que el ORM genera para interactuar con la base de datos relacional física. Esto, en último término, puede llevar a importantes deficiencias en el rendimiento de las aplicaciones. Así, el rendimiento de nuestra aplicación no solo depende del ORM, sino del uso que hacemos de él.

Article available only in Spanish

Este artículo es el primero de una serie de tres que tienen como objetivo analizar las ventajas y desventajas del uso de ORMs (Object Relational Mappings) o, Mapeadores de Objetos Relacionales, así como proporcionar argumentos para decidir su inclusión o no en nuestro desarrollo de aplicaciones con especial atención en cómo afecta su uso al rendimiento global de las mismas.

Here is a link to the meetup we held in the dotNetters community some months ago. IT was amazing for me to talk about such an interesting subjects :)

This little article just tries to point out some important features (from my view) about how BackgroundWorker class works. More in depth, I would like to show what type of threads are executing each piece of code contained in event handlers being consumed by BackgroundWorker objects

The objective of this post is to show, in a hands-on way, the basic use of ordinary delegates and System.Func delegates with normal functions, anonymous functions and lambda expressions (which are actually anonymous functions as well...)