Espacio de Dario Quintana

Los últimos desafíos que estoy experimentando son en Visual Basic. Como bien saben no soy programador de VB nativo pero gracias a unos helpers funciono

Este challenge viene de la mano de:

Visual Basic + Seguridad + Intercepción

Este es el framework (por ahora la foto):

La idea es básicamente contar con una aplicación que pueda denegar a servicios (por abajo de la UI) a usuarios con roles por debajo de los requeridos. Por ejemplo vamos a ver a este servicio, que tiene un mensaje Save:

Como pueden ver el atributo encima del método indica el nivel de autorización que se necesita para acceder al método, sería el Rol. En resumidas cuentas esto nos dice es que si un usuario necesita invocar este método en cualquier implementación de este servicio, él mismo debe cumplir tener ese Rol dentro de la Aplicación, esto es, antes debía haberse autenticado.

Ahora, cómo hacemos la intercepción antes que se ejecute el método? Usando un container que permita tales capacidades, en este caso con ayuda total de Windsor Container.

1) Se solicita un container, en este caso el container se lo extrae del HttpContext.

2) Solicitamos al container una implementación de IUserService, él nos devuelve una instancia envuelta en un proxy. Debemos recordar que los servicios son agnósticos de la capa de presentación (ya sea Winforms or Asp.Net)

3) Cuando ejecutamos Save, se ejecuta primeramente una validación por parte del Framework de Seguridad para ver si el usuario “llamador” cumple con el rol correspondiente. Sino lo hace se lanza una excepción y el método no es invocado. También tenemos intercepción después de terminada la ejecución real del método, si bien decidimos no hacer nada, el framework de seguridad nos permite extender muy fácilmente (implementando 1 clase).

El Framework posee una clase para para la validación previa a la ejecución de los métodos: AspNetInterceptor y esta es la implementación:

Todavía no libero el código, pero en poco tiempo pienso hacerlo como es costumbre

Hace un tiempo escribí este proyecto plantilla usando Spring.Net y NHibernateprincipalmente. Usé NHibernate para el acceso a datos obviamente y Spring.Net para aplicar IoC y Aop.

Esta es la clase CustomerService:

    public class CustomerService : BaseService, ICustomerService
    {
	/// <summary>
        /// This field is inyected by IoC through the property.
        /// </summary>

        private ICustomerDao customerDao;        
 	public ICustomerDao CustomerDao {
            get { return customerDao; }
          set { customerDao = value; }
        }

#region ICustomerService Members

	public int CreateCustomer(string Name, string LastName) {

        	Customer customer = new Customer();

        	customer.FirstName = “Dario”;

	        customer.LastName = “Quintana”;

		CustomerDao.Save(customer);

		return customer.Id;

        }

	public void DeleteCustomer(int Id) {

            	Customer customer = CustomerDao.GetById(Id);

		CustomerDao.Delete(customer);

        }

#endregion

    }

Como se puede apreciar las clases CreateCustomer ó DeleteCustomer no están envueltas en un codigo Transactional o de UnitOfWork, tampoco el método Save(customer) en la clase CustomerDao.

Entonces… donde está el soporte transaccional? Spring + AOP es la respuesta. Spring envuelve a los metodos del Servicio entre transacciones. Y la respuesta para esto son los proxies.

Cuando se realiza la instanciación de la clase CustomerService, un proxy es instanciado. Con el proxy de nuestra clase Spring.Net puede envolver los metodos configurados dentro de transacciones. Muy bueno no ?

Otra cosa que pueden apreciar en el ejemplo es el uso de uNhAddIns en el repositorio. Con esta librería podemos usar queries "detachadas" o separadas de un contexto de persistencia por medio de la clase DetachedQuery. Con DetachedQuery podemos hacer uso indistinto de Hql/SqlNativo en NamedQueries, y esto es una buena práctica que debemos tratar de adoptar.

Descargar el ejemplo

Una de las cosas que me llama notablemente la atención, es la imposibilidad de poder configurar Db4o por medio de Xml, siendo algo tan común hoy en día y por sobre todo naciendo en Java.

La respuesta del lado de Java está justificada, no así del todo del lado de .Net. En Java, yo creo que la mayoría de los que usan Db4o usan el módulo de Spring para poder configurarla y obviamente no solo para eso, para usar las ventajas de IoC y Aop que posee Spring.

Algo básico que permite el módulo de Spring para Db4o es la capacidad de envolver a métodos que uno seleccione (y configure correctamente) en transacciones, de modo de abstraernos de este aspecto a nosotros.

Por que digo que no está tan justificado del lado de .Net, por que Spring del lado de .Net no es tan aceptado como lo es del lado de Java, que es donde nació. Y entonces mucho menos será entonces la adopción de dicho módulo pero para .Net.

Que lindo sería si se podría configurar Db4o de esta manera: 

<?xml version=”1.0″ encoding=”utf-8″ ?>
<db4o assembly=”db4oif.Test” namespace=”db4oif.Test.Objects”>
    <class name=”Customer”>
        <field name=”_id” unique=”true” indexed=”true”/>
    </class>

    <class name=”Product”>
        <field name=”_name” unique=”true” indexed=”true”/>
    </class>

    <class name=”db4oif.Test.Objects, db4oif.Test”>
        <field name=”_name” unique=”true” indexed=”true”/>
    </class>
</db4o>

Cualquier semejanza con un mapping file de NHibernate es pura coincidencia

Esto lo había expuesto aquí en el foro de la comunidad de Db4o, algún día espero tomarme el tiempo para escribir las clases de configuración, pero supongo que terminaré usando el módulo Spring que ya lo hace por mí (entre otras cosas).

Un nuevo Application Block nació: Policy Injection Application Block.

Al parecer, con este nuevo App Block podremos aplicar conceptos como el de SoC (Separation of concerns) en nuestra aplicación, tal como lo venían predicando de manera similar frameworks como Spring.Net.

Para ser claro, podriamos hacer que en un objeto de nuestra aplicación, al ejecutarse un método, realice una entrada al archivo de log, de forma transparente en el código cliente. 

Esto se pone más interesante, en la interoperabilidad que podremos llegar a tener con otros App Blocks, como ser: Validation, Logging, Exception entre otros.

La idea básica es trabajar con una factoría de clases, para la instanciación de nuestros objetos. Dicha factoria inspeccionará la configuración, para ver si el objeto posee politicas que aplicar, si no las posee, se crea una instancia común y corriente, si las posee, se crea un proxy para que el framework pueda manejar al objeto de forma transparente al cliente.

Escenario donde podriamos aplicar:

En nuestra aplicación un objeto que posee un método Guardar(Cliente obj). Utilizando estos conceptos, podríamos hacer que cada vez que se llame a este método, es decir, que querramos guardar un cliente, por medio del Policy Injection App Block se realize la validación del objeto (utilizando el Validation App Block), y si no es una entidad válida, dicho método Guardar no se ejecute.

Para más lean estos posts:

• Announcing the Policy Injection Application Block
• Policy Injection App Block - Behind the Scenes