Уровень доступа к данным - класс проектирования, где должна быть ответственность за создание сохранения

Question

Я разрабатываю Уровень доступа к данным с помощью ADO.NET 2.0 и C #, Sql Server 2005. Я часто пытаюсь понять, где разместить эти вызовы. Каким образом из приведенного ниже я должен следовать для обеспечения надежного кода.

Метод 1

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}

public bool Create()
{
}

public bool Update()
{
}

public bool Delete()
{
}

}

Метод 2

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}
}

и я бы использовал другой класс, как показано ниже, для доступа к основным данным. Как ниже

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

Использование метода 2. Класс Компании не несет ответственности за чтение / запись из источника данных ( принцип единственной ответственности ).Тем не менее, я бы даже пошел до создания ICompanyRepository интерфейса и затем создания CompanyRepository реализации для интерфейса.Таким образом вы можете внедрить ICompanyRepository в класс, который должен сохранять / извлекать информацию о компании.Это также позволяет упростить модульное тестирование и создать в будущем другую реализацию (переключение с базы данных на XML-файлы и т. Д.).

Answer 2

Если вы будете следовать принципу разделения интересов , вы пойдете по своему методу 2.

Наличие разных обязанностей в разных классах помогает в создании тестируемого, поддерживаемого кода.

Это также дает меньшие, более сплоченные классы, которые легче писать, рассуждать и проверять правильность.

Как примечание, вы можете использовать ORM вместо ручной обработки слоя доступа к данным.

Answer 3

Я бы за второй вариант, потому что

• сначала вы создаете data holder
• после того, как ваш operational unit

Таким образом, в этом случае вы отделяете данные от функций, которые над ними работают, что значительно облегчает UnitTesting и распределяет обязанности между различными областями вашего кода с, возможно, легкой локализацией ошибок.