Este challenge viene de la mano de:

Este es el framework (por ahora la foto):

La idea es básicamente [...]]]> 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

Esta es la clase CustomerService:

La respuesta del lado de Java está justificada, no así del todo del lado de .Net. En Java, yo [...]]]> 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).

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 [...]]]> 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