Определение уровня доступа к данным

Question

Кажется, все знают, что у вас должно быть четкое различие между графическим интерфейсом, бизнес-логикой и доступом к данным.Недавно я разговаривал с программистом, который хвастался тем, что у него всегда есть чистый уровень доступа к данным.Я просмотрел этот код, и оказалось, что его уровень доступа к данным - это всего лишь небольшой класс, содержащий несколько методов SQL (таких как ExecuteNonQuery и ExecuteReader).Оказывается, что в его ASP.NET коде за страницами у него есть тонны SQL, жестко закодированных в page_load и других событиях.Но он клянется, что использует уровень доступа к данным.

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

Answer 1

То, о чем говорит ваш коллега, по мнению большинства людей, не DAL. DAL должен инкапсулировать любые обращения к базе данных, будь то с помощью динамического SQL, хранимых процедур или ORM с чем-то вроде IRepository. Ваши веб-страницы никогда не должны содержать SQL или бизнес-логику, иначе это станет кошмаром обслуживания.

Answer 2

Очень простой пример для .NET будет следующим.

Если есть два класса: SomePage (это страница ASP.NET) а также DataService (это старый класс C #)

Если SomePage всегда вызывает DataService для чтения / записи данных, у вас есть слой доступа к данным. SomePage не будет содержать SQL или ссылок на классы System.Data.SqlClient.

Но SomePage может использовать DataSets или бизнес-объекты, которые передаются из класса DataService и в него.

Answer 3

Я нашел эту статью о создании DAL:

http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/

Answer 4

В дополнение к тому, что говорили другие, я обычно считаю, что это место, чтобы абстрагироваться от того, как хранятся ваши данные. Действительно хороший уровень доступа к данным должен позволять вам заменять Oracle, SQL Server, Access, простой текстовый файл, XML или все, что вы хотите, и это будет прозрачно для других прикладных уровней. Другими словами, контракт между уровнем доступа к данным и другими уровнями должен определяться независимо от базы данных.

Answer 5

Я лично определяю DAL как место, где существуют взаимодействия между моим приложением и базой данных. Поэтому у меня может быть бизнес-уровень, который взаимодействует с DAL для разрешения операций CRUD.

Например, у меня может быть метод ModelClass.LoadAll (), который будет взаимодействовать с DAL, который будет извлекать данные, а ModelClass будет использовать эти данные любым нужным способом.

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

Answer 6

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

Answer 7

Цитата &; Черная коробка & цитата; который содержит ваши данные. Если он заботится о пользователях / может сказать, что там есть БД (не считая каждого рассмотрения), это не совсем то, о чем я думаю

Answer 8

Я бы с удовольствием поделился этим дизайном устройство для получения данных слой (доступный только для чтения).

Ключи к архитектуре:

• Идея состоит в том, чтобы создать объект, который является почти одноэлементным (объяснено ниже), который должен содержать данные, которые извлекаются с помощью get-методов - ниже я называю это DRO (DataRetrieverObject).
• Объекту-клиенту должно быть легко добраться до DRO.
• Поддерживать занятия должно быть легко.

Структура основана на трехступенчатом построении.

1. Используйте DataRetrieverFactory наличие (перегруженных) статических методов, по одному для каждой нужной вам таблицы.Используйте перегрузку для сопоставления различных типов ключей.Метод вернет значение DRO.

2. Тот Самый DataRetrieverFactory делегируйте строительные работы второму классу <TableNameAndKey>DR это создаст фактический DRO.

3. В <TableNameAndKey>DR у нас есть статический список указателей на DRO, просмотрите список, чтобы увидеть, есть ли у вас уже DRO с определенным ключом.

   3.1.Если вы найдете DRO - проверьте, все ли в порядке (имеется в виду:

   • он не должен быть "старым".,
   • он должен принадлежать сеансовому запуску,
   • и т.д.)

   3.1.1.Если DRO в порядке - тогда верните DRO.

   3.1.2.Если DRO не в порядке, удалите объект (и его указатель) и создайте новый DRO с данными из базы данных.Сохраните указатель в списке.

   3.2.Если в списке указателей нет попадания, то мы создаем новый DRO с данными из базы данных и сохраняем указатель в статическом списке.

Используя этот метод, можно повторно использовать DRO в зависимости от необходимости, однако класс не является одноэлементным, поскольку нам разрешено иметь множество экземпляров класса.