Camada de acesso a dados - classe de projeto onde deve ser a responsabilidade de criar a economia

Question

Estou projetando a camada de acesso a dados com ADO.NET 2.0 e C #, Sql Server 2005. Freqüentemente, luto com meu cérebro para decidir onde fazer essas chamadas. Qual das opções a seguir devo seguir para obter um código robusto de manutenção.

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;}
}

e eu usaria outra classe como a abaixo para fazer o acesso aos dados principais.Como abaixo

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

Vá para o método 2. Não é responsabilidade da classe Company ler / gravar a partir de uma fonte de dados ( princípio de responsabilidade única ).No entanto, eu iria até mesmo criar uma interface ICompanyRepository e, em seguida, criar uma implementação CompanyRepository para a interface.Dessa forma, você pode injetar o ICompanyRepository na classe que precisa salvar / recuperar informações da empresa.Também permite testes de unidade mais fáceis e a capacidade de criar uma implementação diferente no futuro (alternar de um banco de dados para arquivos xml ou qualquer outro).

Answer 2

Se você seguir o princípio de separação de interesses , seguirá com seu método 2.

Ter responsabilidades diferentes em classes diferentes ajuda a criar código testável e sustentável.

Isso também produz classes menores e mais coesas que são mais fáceis de escrever, raciocinar e verificar se estão corretas.

Como observação, você pode usar um ORM em vez de criar manualmente seu acesso aos dadoscamada.

Answer 3

Eu defendia a segunda escolha, porque

• primeiro você cria seu data holder
• depois de criar seu operational unit

Então, neste caso, você separa os dados das funções que operam neles, tornando UnitTesting notavelmente mais fácil e destruindo as responsabilidades entre os diferentes domínios do seu código, com, possivelmente, localizações fáceis de bugs.