Livello di accesso ai dati - Classe di progettazione in cui dovrebbe essere la responsabilità della creazione del risparmio

Question

Sto progettando Data Access Layer con ADO.NET 2.0 e C #, Sql Server 2005. Spesso combatto con il mio cervello su dove collocare queste chiamate. Quale strada di seguito dovrei seguire per un codice robusto e manutenibile.

Metodo 1

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}

public bool Create()
{
}

public bool Update()
{
}

public bool Delete()
{
}

}

Metodo 2

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}
}

e userei un'altra classe come quella di seguito per eseguire l'accesso ai dati di base.Come sotto

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

Procedi con il metodo 2. Non è responsabilità della classe Company leggere / scrivere da un'origine dati ( principio di responsabilità unica ).Tuttavia, mi spingerei persino a creare un'interfaccia ICompanyRepository e quindi a creare un'implementazione CompanyRepository per l'interfaccia.In questo modo puoi iniettare ICompanyRepository nella classe che deve salvare / recuperare le informazioni sulla società.Consente inoltre un test di unità più semplice e la possibilità di creare un'implementazione diversa in futuro (passando da un database a file xml o altro).

Answer 2

Se segui il principio della separazione delle preoccupazioni , seguirai il tuo metodo 2.

Avere responsabilità diverse in classi diverse aiuta nella creazione di codice verificabile e gestibile.

Questo produce anche classi più piccole e più coese che sono più facili da scrivere, ragionare e controllare per correttezza.

Come nota, puoi utilizzare un ORM invece di creare manualmente l'accesso ai datistrato.

Answer 3

Rappresenterei la seconda scelta, perché

• prima crei il tuo data holder
• dopo aver creato il tuo operational unit

Quindi in questo caso si separano i dati dalle funzioni che operano su di essi, rendendo il UnitTesting notevolmente più semplice e distribuendo le responsabilità tra i diversi domini del proprio codice, con, possibilmente, facili localizzazioni di bug.