Sobre arquitectura en capas – parte 2

Desde hace algún tiempo, cuando un proyecto necesita acceder a una base de datos relacional, lo común es utilizar un ORM. El ORM se encarga de realizar la conversión desde objetos/colecciones en el lenguaje de OOP a registros/tablas en el modelo relacional y viceversa. En otros proyectos se ha optado incluso por usar una base de datos no relacional (NoSQL), donde no es siquiera necesario el mapeo entre clases y tablas. El uso de estas herramientas (ya sea ORM o NoSQL) nos ayuda a trabajar en un nivel más alto de abstracción. Ya no vemos SQL directamente, ahora trabajamos con objetos (entidades) como nuestros datos.

Si seguimos con el ejemplo del artículo anterior, donde se nos pide que un usuario pueda ingresar a un sistema usando su nombre y contraseña. Al usar herramientas como EntityFramework (un ORM) podemos cambiar nuestra capa de acceso a datos.La cual pudiera usar EF para realizar las consultas y actualizaciones. De esta forma no necesitamos escribir SQL y seguimos con nuestra misma arquitectura en 3 capas. Quedando el código algo así:

public User FindByUsername(string username)
{
  var db = new MySampleAppContext();
  return db.Users.SingleOrDefault(user => user.Username == username);
}

Pero nuestro objetivo no es tener 3 capas, ese era solo un medio para un fin. Recordemos para qué tenemos nuestra capa de acceso a datos. La capa de acceso a datos existe para que la capa de reglas de negocios no tenga que ”pensar” en detalles de tablas, registros y SQL. Es la misma razón por la que existen los ORMs, para abstraer el acceso a datos. Entonces… nuestra capa de acceso a datos es una abstracción del ORM que a su vez es una abstracción del acceso a datos, una abstracción redundante. Debemos de limitar nuestras abstracciones por lo que podemos utilizar el ORM directamente en nuestra capa de negocio. De ese modo podemos aprovechar mejor las características de la herramienta y nos ahorramos el trabajo de mantener una capa ya innecesaria. Comparemos el código de la capa de negocios con y sin una capa de acceso a datos.

//con capa de acceso a datos
public bool ValidateUser(string username, string password)
{
    var userRepository =  new Dal.UserRepository();
    var user = userRepository.FindByUsername(username);
    if (user == null) return false;
    var cryptoService = new CryptoService();
    return cryptoService.ComputeHash(password) == username.Password;
}

//Usando ORM en la capa de negocios
public bool ValidateUser(string username, string password)
{
    var db =  new MySampleAppContext();
    var user = db.Users.SingleOrDefault(x => x.Username == username);
    if (user == null) return false;
    var cryptoService = new CryptoService();
    return cryptoService.ComputeHash(password) == username.Password;
}

Podemos ver que el código es muy similar; pero usando EF ya nos ahorramos una capa (un proyecto). Podemos hacer uso de características de EF desde nuestra capa de reglas de negocio (como lazy loading, entre otras) sin tener que tratar de replicarlas en nuestra capa de acceso a datos.

En conclusión podemos decir que ahora, con el uso de herramientas como ORM (o una base de datos no relacional), ya no es necesario crear una capa de acceso a datos porque las herramientas cumplen con el propósito que tenia esa capa. La capa de acceso a datos tenia sentido cuando escribíamos SQL directamente en nuestra aplicación; pero ya no.

Artículo relacionado: Sobre arquitectura en capas – parte 1