«Тонкий слой доступа к данным» в основном подразумевает написание SQL вручную?

Question

Когда вы говорите «тонкий слой доступа к данным», означает ли это, что вы в основном говорите о написании SQL вручную, а не о том, что для его создания вам нужен инструмент ORM?

Answer 1

Это, вероятно, зависит от того, кто это говорит, но для меня тонкий уровень доступа к данным подразумевал бы, что на уровне почти нет никакой дополнительной логики (т. Е. Абстракций хранения данных), вероятно, нет поддержки нацеливания на несколько СУБД, нет уровня. специальное кэширование, отсутствие расширенной обработки ошибок (повтор, отказоустойчивость) и т. д.

Поскольку инструменты ORM, как правило, снабжают многие из этих вещей, решение с ORM, вероятно, не будет считаться «тонким». Многие домашние уровни доступа к данным также не будут считаться «тонкими», если они предоставляют функции, подобные перечисленным выше.

Answer 2

Я думаю, что "худой" в этом контексте означает:

1. Легкий;
2. имеет низкую производительность; и
3. Вы пишете минимальный код.

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

Answer 3

Зависит от того, как мы определяем слово «худой». Это один из самых оскорбительных терминов, которые я слышал, его можно сравнить только с «легким».

Это один из способов определить это, но, возможно, не самый лучший. Слой ORM делает многое, помимо того, что генерирует для вас SQL (например, кеширование, пометка «грязных» полей и т. Д.). Этот «тонкий» слой, написанный на любовно созданном SQL, может стать довольно раздутым к тому времени, когда вы реализуете все функции ORM обеспечивает.

Answer 4

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

Может быть, человек, с которым вы говорили, говорит о сочетании бизнес-уровня и уровня доступа к данным; если бизнес-уровень не существует (например, очень простое приложение или, возможно, все бизнес-правила находятся в базе данных и т. д.).

Answer 5

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

Answer 6

Я думаю, это зависит от контекста.

Это вполне может означать, или просто может означать, что ваши бизнес-объекты отображают непосредственно простую базовую структуру реляционной таблицы: одна таблица на класс, один столбец на атрибут класса, так что перевод структуры бизнес-объекта в таблицу базы данных структура "тонкая" (т.е. не сложная). Конечно, это все еще может быть обработано ORM.