Row Level Security in SQL Server

Row-Level Security let us control access to data at row level for any SQL Server table based on users, roles, membership or working context. It tremendously simplifies and improve the options we have to secure, filter, implement restrictions or eventually deal with our data over certain scenarios. What is most relevant for me is that all the security policy can be set centrally at a database level preventing developers from taking care of adding custom where clauses to enforce security. It makes the management of data much more reliable and maintainable.


Provider design pattern at a glance

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.


How to optimize an Object Relational Mapper (ORM)?

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.