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

Question

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

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

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

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

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

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

   • это не должно быть «старый»,
   • она должна принадлежать сессионный перспективе,
   • и т.д.)

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

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

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

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