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

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

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


data-access-layer
person Jim    schedule 12.11.2008    source источник
comment
Доступ к базе данных и наличие уровня доступа к данным - это не одно и то же. Тем не менее, для доступа к базе данных необходимо использовать какую-либо форму уровня доступа к данным, чтобы я мог понять путаницу.   -  person user924272    schedule 14.05.2016

Ответы (8)


arrow_upward
9
arrow_downward

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

person Craig    schedule 12.11.2008
comment
+1 для большей части этого. Однако динамический SQL часто указывает на плохо спроектированный уровень доступа. - person S.Lott; 12.11.2008

arrow_upward
5
arrow_downward

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

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

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

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

person BuddyJoe    schedule 12.11.2008

arrow_upward
3
arrow_downward

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

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

person VoltaicShock    schedule 10.08.2010

arrow_upward
2
arrow_downward

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

person CodingWithSpike    schedule 12.11.2008

arrow_upward
1
arrow_downward

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

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

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

person JamesSugrue    schedule 12.11.2008
comment
Для меня DAL - это просто место, которое выполняет мой CRUD и подключается только к БД. - person VoltaicShock; 10.08.2010

arrow_upward
1
arrow_downward

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

person IrishChieftain    schedule 04.12.2008

arrow_upward
0
arrow_downward

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

person BCS    schedule 12.11.2008

arrow_upward
0
arrow_downward

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

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

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

В основе конструкции лежит трехступенчатая конструкция.

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

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

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

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

    • it should not be "old",
    • он должен принадлежать запущенному сеансу,
    • и т.д.)

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

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

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

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

person AD.    schedule 10.04.2012
comment
См. Объект доступа к данным для получения информации о стандартном подходе. - person user924272; 14.05.2016