Data Mapper Design Pattern и шлюзы - вопрос новичка

Question

Пожалуйста, поправьте меня, если я ошибаюсь:

Если мы используем шаблон Dao/Vo или шаблон TDG, у нас будет хорошая организация кода, поскольку для каждой (или, по крайней мере, для многих) таблиц имеется связанный класс.

Проблема с этим подходом состоит в том, что или данные НЕ закрыты внутри данной таблицы. У нас есть некоторые доменные данные, такие как findDogBreed(); или же findBookBestSellerAuthor(); и вышеупомянутые образцы, кажется, не справляются с этим приятно.

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

Проблема в том, что если мы начнем абстрагировать все эти вещи, у нас НЕ будет доступа к синтаксису SQL. Что если нам понадобится наш администратор базы данных для работы над ним? А в более сложных запросах использование картографов может привести к очень грязной абстракции.

Это правильно? Если это так, мне интересно, какие пути у нас есть, чтобы найти здесь средний термин.

Answer 1

Вам не нужно терять возможность писать SQL вручную, когда вы абстрагируете функциональность, даже на нескольких уровнях абстракции.

Например, взгляните на Doctrine, который является вдохновляющим Hibernate ORM для PHP. Он позволяет вам писать запросы на языке DQL (Doctrine Query Language), который переводит в SQL и автоматически сопоставляет ваши сущности, но вы также можете написать собственный SQL (чаще всего для оптимизации производительности), но вам нужно определить отображение результатов самостоятельно.