Couche d'accès aux données - Cours de conception où devrait la responsabilité de créer une sauvegarde
-
28-10-2019 - |
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)
{
}
}
La solution
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).
Autres conseils
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.
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.