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