Data Access Layer - Designing Class where should responsibility of creating saving be
-
16-04-2021 - |
题
I am designing Data Access Layer with ADO.NET 2.0 and C#, Sql Server 2005. I often fight with my brain over where to place those calls. Which way of the below i should follow for maintainable robust code.
Method 1
Public Class Company
{
public string CompanyId
{get;set;}
public string CompanyAddress
{get;set;}
public bool Create()
{
}
public bool Update()
{
}
public bool Delete()
{
}
}
Method 2
Public Class Company
{
public string CompanyId
{get;set;}
public string CompanyAddress
{get;set;}
}
and i would use another class like below to do the core data access. Like below
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)
{
}
}
解决方案
Go with method 2. It is not the Company class's responsibility to read/write from a data source (single responsibility principle). However, I would even go as far as creating an ICompanyRepository
interface and then creating a CompanyRepository
implementation for the interface. This way you can inject the ICompanyRepository into the class that needs to save/retrieve company information. It also allows easier unit testing and the ability to create a different implementation in the future (switching from a database to xml files or whatever).
其他提示
If you follow the principle of separation of concerns, you will go with your method 2.
Having different responsibilities in different classes does help with creating testable, maintainable code.
This also produces smaller, more cohesive classes that are easier to write, reason about and check for correctness.
As a note, you can use an ORM instead of hand crafting your data access layer.
I would stand for second choice, cause
- first you create your
data holder
- after crate your
operational unit
So in this case you separate the data from functions that operate on them, making UnitTesting
notably easier and destributing the responsibilities between different domains of your code, with, possibly, easy bugs localizations.