Определить уровень доступа к данным - PullRequest
Новая
       8

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

7 голосов
/ 12 ноября 2008

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

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

Ответы [ 8 ]

9 голосов
/ 12 ноября 2008

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

5 голосов
/ 12 ноября 2008

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

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

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

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

3 голосов
/ 10 августа 2010
2 голосов
/ 12 ноября 2008

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

1 голос
/ 04 декабря 2008

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

1 голос
/ 12 ноября 2008

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

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

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

0 голосов
/ 10 апреля 2012

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

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

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

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

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

  2. DataRetrieverFactory делегирует задание на строительство второму классу <TableNameAndKey>DR, который создаст фактическое УЦИ.

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

    3,1. Если вы нашли УЦИ - проверьте, все ли в порядке (имеется в виду:

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

    3.1.1. Если УЦИ в порядке - верните УЦИ.

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

    3,2. Если в списке указателей нет попаданий, мы создаем новое УЦИ с данными из БД и сохраняем указатель в статическом списке.

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

0 голосов
/ 12 ноября 2008

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

...