Capa de acceso a datos: clase de diseño donde debería estar la responsabilidad de crear ahorros

Question

Estoy diseñando Capa de Acceso a Datos con ADO.NET 2.0 y C#, Sql Server 2005.A menudo peleo con mi cerebro sobre dónde realizar esas llamadas. ¿Qué camino de lo siguiente debo seguir para obtener un código robusto y mantenible?

Método 1

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}

public bool Create()
{
}

public bool Update()
{
}

public bool Delete()
{
}

}

Método 2

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}
}

y usaría otra clase como la siguiente para realizar el acceso a los datos principales.Como abajo

Public Class CompanyRepository
{

public Company CreateCompany(string companyId,string companyDescription)
{
}

public bool UpdateCompany(Company updateCompany)
{
}

public bool DeleteCompany(string companyId)
{
}

public List<Company> FindById(string id)
{
}


}

Answer 1

Opte por el método 2. No es responsabilidad de la clase Company leer / escribir desde una fuente de datos ( principio de responsabilidad única ).Sin embargo, incluso iría tan lejos como para crear una interfaz ICompanyRepository y luego crear una implementación CompanyRepository para la interfaz.De esta manera, puede inyectar ICompanyRepository en la clase que necesita guardar / recuperar información de la empresa.También permite pruebas unitarias más sencillas y la capacidad de crear una implementación diferente en el futuro (cambiar de una base de datos a archivos xml o lo que sea).

Answer 2

Si sigue el principio de separación de preocupaciones , seguirá su método 2.

Tener diferentes responsabilidades en diferentes clases ayuda a crear código comprobable y mantenible.

Esto también produce clases más pequeñas y cohesivas que son más fáciles de escribir, razonar y verificar si son correctas.

Como nota, puede utilizar un ORM en lugar de crear manualmente su acceso a los datos.capa.

Answer 3

Yo elegiría la segunda opción, porque

• primero creas tu data holder
• después de caja tu operational unit

Entonces, en este caso, separa los datos de las funciones que operan sobre ellos, haciendo UnitTesting notablemente más fácil y distribuyendo las responsabilidades entre diferentes dominios de su código, con, posiblemente, localización de errores sencilla.