Siguiendo el excelente ejemplo que puso Rocky de su arquitectura de clases propuesta, les voy mostrar la arquitectura de clases que estoy proponiendo para un nuevo proyecto que estamos desarrollando para una empresa de prestamos monetarios $$$$$ :D
Al referirnos a un ensamblado DAL (Capa de acceso a datos) tiene que ver invariablemente con acceso a datos relacionado con una arquitectura basada en capas (al menos las 3 capas básicas Presentación, Reglas de negocio y Acceso a Datos)
Las acciones a ejecutar dentro de nuestro DAL normalmente siempre son las mismas, Agregar, Eliminar y Consultar registros, entonces, al ser acciones repetitivas, por que no crear una interface y con esto, crear un "contrato" común para todas nuestras clases, en este caso, por motivos que mas adelante les contare decidí crear una clase abstracta que implemente dichas opciones comunes:
public abstract class Entidad
{
#region "Métodos protegidos"
protected string nombre;
protected bool estatus;
#endregion
#region "Propiedades virtuales"
public virtual int Id
{
get { return id; }
set { id = value; }
}
public virtual string Nombre
{
get { return nombre; }
set { nombre = value; }
}
public virtual bool Estatus
{
get { return estatus; }
set { estatus = value; }
}
#endregion
#region Métodos virtuales
public virtual bool Agregar()
{
throw new Exception("The method or operation is not implemented.");
}
public virtual bool Actualizar()
{
throw new Exception("The method or operation is not implemented.");
}
public virtual bool Eliminar()
{
throw new Exception("The method or operation is not implemented.");
}
public virtual System.Data.DataSet Consultar()
{
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
La mayoría de nuestras clases tienen que ver con catálogos ¿cierto? Pues en este caso, la clase abstracta además de darnos las acciones comunes también nos provee los elementos más comunes de un catalogo:
Al crear una clase abstracta tenemos la posibilidad de crear una clase parcialmente implementada, ya que como pueden ver en el ejemplo anterior, existe la propiedad Nombre que está 100% implementada, sin embargo, los métodos Agregar, Actualizar, Eliminar y Consultar no tienen implementación real (lo cual nos da una clase parcialmente implementada), entonces, si no tienen implementación por que no marcarlos como abstract en lugar de virtual, básicamente, en mi caso es cuestión de "comodidad" ya que al marcarla como abstract me obliga a realizar la implementación completa de dichos métodos aún cuando no los necesite, es decir, si la clase que estoy implementando únicamente es de consulta, lo métodos de Agregar, Actualizar etc no los necesito y por ende lo único que harían seria lanzar una excepción, al marcarla como virtual esto no sucede, ya que el código que se ejecutara al no estar implementado será el de la clase base con lo cual me "ahorro" el tener que estar implementando lo mismo para las clases que no implementen todos los métodos. Quedara más claro cuando ya veamos el ejemplo implementado.
Ok, en este punto ya tenemos nuestra clase base ¿Qué falta? Pues las clases que implementaran ahora si el código especifico, diría Ernesto, la carnita :D, siguiendo el ejemplo de Rocky, creare una clase llamada Banco y otra más llamada TipoCuenta
Clase Banco
public class Banco:Entidad
{
public override bool Agregar()
{
//aquí va el código para agregar
}
public override bool Actualizar()
{
//aquí va el código para actualizar
}
public override bool Eliminar()
{
//aquí va el código para eliminar
}
public override System.Data.DataSet Consultar()
{
return Util.ObtenerCatalogo("Bancos");
}
}
Clase Tipo de Cuenta de solo consulta, no necesitamos los metodos agregar, eliminar etc.
public class TipoCuenta:Entidad
{
//Esta clase solo tiene implementado el método de consultar
public override System.Data.DataSet Consultar()
{
return Util.ObtenerCatalogo("TiposCuenta");
}
}
Mañana le seguimos y vemos el por que de estás implementaciones, creo que nos esperan varios post :D.