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 и автоматически отображает ваши сущности, но вы также можете написать native SQL (чаще всего для оптимизации производительности), но вам нужно определить сопоставление результатов самостоятельно.