Couche d'accès aux données - Cours de conception où devrait la responsabilité de créer une sauvegarde

Question

Je conçois la couche d'accès aux données avec ADO.NET 2.0 et C #, SQL Server 2005. Je me bats souvent avec mon cerveau sur où passer ces appels. Quelle voie de ce qui est ci-dessous, je dois suivre pour le code robuste maintenable.

Méthode 1

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}

public bool Create()
{
}

public bool Update()
{
}

public bool Delete()
{
}

}

Méthode 2

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}
}

Et j'utiliserais une autre classe comme ci-dessous pour effectuer l'accès aux données de base. Comme ci-dessous

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

Allez avec la méthode 2. Ce n'est pas la responsabilité de la classe d'entreprise de lire / écrire à partir d'une source de données (Principe de responsabilité unique). Cependant, j'irais même jusqu'à créer un ICompanyRepository interface puis créant un CompanyRepository implémentation pour l'interface. De cette façon, vous pouvez injecter l'icompanyRepository dans la classe qui doit enregistrer / récupérer les informations de l'entreprise. Il permet également des tests unitaires plus faciles et la possibilité de créer une implémentation différente à l'avenir (passer d'une base de données aux fichiers XML ou autre).

Answer 2

Si vous suivez le principe de séparation des préoccupations, vous irez avec votre méthode 2.

Avoir des responsabilités différentes dans différentes classes aide à créer un code testable et maintenable.

Cela produit également des classes plus petites et plus cohésives qui sont plus faciles à écrire, à raisonner et à vérifier l'exactitude.

À titre de note, vous pouvez utiliser un Orm Au lieu de fabriquer la manche de votre couche d'accès aux données.

Answer 3

Je défendrais le deuxième choix, car

• Vous créez d'abord votre data holder
• Après la caisse operational unit

Donc, dans ce cas, vous séparez les données des fonctions qui fonctionnent sur eux, en faisant UnitTesting Notamment plus facile et destructant les responsabilités entre différents domaines de votre code, avec, éventuellement, des localisations de bogues faciles.