Desarrollar en 3 capas con .NET y NHibernate - Parte 1 (Acceso a datos)

Luego de haber posteado que es el diseño en 3 capas, y que es un ORM con ejemplos de NHibernate, estamos en condiciones de comprender el desarrollo de software mediante esta arquitectura con el framework .NET.
Echemos un vistazo a este diagrama de componentes que aplica esta arquitectura de 3 capas (para el desarrollo de un sistema de viáticos):


















Podemos ver que además de las capas de presentación, procesos del negocio y acceso a datos, tenemos los objetos de negocio aparte como si de otra capa se tratase. Aunque en la realidad debería estar en la capa del medio, esto presenta problemas en la capa de acceso a datos que pasaría a desconocer los objetos con los que debe trabajar NHibernate en nuestras clases DAO. Para comprender claramente de que estoy hablando debemos ver las clases que se encuentran en cada componente de software.

Empezando por el acceso a datos:




















NHibernateCore

Aqui estan : una interfaz para los DAO (data access object) genérica (IDAO), una clase abstracta que implementa IDAO (NHibDAOAbstracto), y manejo de sesiones y transacciones de NHibernate. Su contenido responde al excelente trabajo de Billy McCafferty: NHibernate best practices with ASP.Net, cuya lectura recomiendo, antes de comenzar a desarrollar una capa de acceso a datos.

Por ej. IDAO:

public interface IDAO // maneja Generics de Net 2.0
{
T GetById(IdT id, bool shouldLock);
List GetAll();
List GetByExample(T exampleInstance, params string[] propertiesToExclude);
T GetUniqueByExample(T exampleInstance, params string[] propertiesToExclude);
List Find(string consulta);
IList FindRetLista(string consulta);
T Save(T entity);
T SaveOrUpdate(T entity);
void Delete(T entity);
void CommitChanges();
}

ViaticoDAO

Aquí se encuentran : la fábrica de DAOs, y los DAO de cada objeto de negocio.
Por ej. la clase SolicitudDAO :
public class SolicitudDAO : NHibDAOAbstracto, ISolicitudDao
// Hereda del DAO abstracto definido en NHibernateCore e implementa ISolicitudDao
// para no hacer uso directo del DAO abstracto
{

public List DarSolicitudesXSolicitante(Solicitante s, Nullable Desde, Nullable Aprobadas)
{
string criterios = "FROM Solicitud a WHERE a.Solicitante.ID = " + s.ID.ToString();

if (Desde != null)
criterios += " and Fecha_soli >=" + ((DateTime)Desde.Value).ToShortDateString();
if (Aprobadas != null)
{
if (Aprobadas == true)
criterios += " and Aprobada=1";
else
criterios += " and Aprobada=0";
}

IDaoFabrica daoFabrica = new DAOFabrica();
ISolicitudDao soliDao = daoFabrica.GetSolicitudDao();

List solicitudes;
solicitudes = soliDao.Find(criterios);
return solicitudes;
}

public Solicitud DarSolicitudXid(int id)
{
IDaoFabrica daoFabrica = new DAOFabrica();
ISolicitudDao soliDao = daoFabrica.GetSolicitudDao();

Solicitud s = soliDao.GetById(id, false);
return s;
}
}

ISolicitudDao:

public interface ISolicitudDao : IDAO
{
List DarSolicitudesXSolicitante(Solicitante s, Nullable Desde, Nullable Aprobadas);

Solicitud DarSolicitudXid(int id);
}

Por último un ejemplo de DAOFabrica:

public class DAOFabrica : IDaoFabrica
{
public IEmpleadoDao GetEmpleadoDao()
{
return new EmpleadoDAO();
}

public ICategoriaDao GetCategoriaDao()
{
return new CategoriaDAO();
}

public ISolicitudDao GetSolicitudDao()
{
return new SolicitudDAO();
}
...
}

Lo destacable en esta capa de acceso a datos es su independencia del motor de NHibernate, gracias al uso de la Fábrica de DAOs. Por ej. si quisiera reemplazar el NHibernate por Linq for Sql (del Net 3.0), cambiaría en mis DAOs la herencia de la clase abstracta que implementa los métodos contra el motor de acceso a datos:
public class SolicitudDAO : NHibDAOAbstracto, ISolicitudDao por
public class SolicitudDAO : LinqDAOAbstracto, ISolicitudDao

Por supuesto deberé desarrollar mi clase LinqDAOAbstracto para que implemente los métodos de la interfaz IDAO.

En parte 2 veremos la capa de negocio (procesos y reglas; ó controladoras de los casos de uso) y ejemplos de los objetos de negocio, cuyas clases están implementadas en su propio componente.