Espacio de Dario Quintana

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).