Нарушает ли шаблон DataMapper MVC?

Используя объекты-значения, вы можете исключить некоторые из этих общедоступных методов установки. Вот описание различия между объектами Entity и Value Objects. Объекты-значения неизменяемы и часто привязаны к сущности. Если вы передаете все значения с помощью конструктора, вам не нужно устанавливать эти свойства из внешнего кода.

Что-то дополнительное, не связанное напрямую с ответом, но больше ориентированное на DDD:

(Отказ от ответственности: единственное, что я знаю о Zend Framework, это то, что я прочитал в связанной статье.) Zend Framework использует DataMappers вместо репозиториев. Это действительно DDD-иш? Что ж, интерпретация репозитория Фаулером может сказать нет. Однако Эрик Эванс утверждает, что репозиторий DDD может быть очень простым. В простейшем случае репозиторий является DataMapper (см. книгу DDD). Что-то более сложное и все еще DDD смотрите в статье Фаулера. DDD имеет концептуальный репозиторий, который может отличаться от определения шаблона.

Я призываю вас продолжать читать о проектировании, управляемом предметной областью. Я думаю, что есть ошибка в предположении, что геттеры и сеттеры нарушают DDD. DDD фокусируется на модели предметной области и лучших практиках для достижения этой цели. Аксессуары — это всего лишь незначительная деталь.

Вам не нужно реализовывать все геттеры/сеттеры, вы можете использовать __get() и __set(). В чем тогда проблема?

Судя по моему чтению поста, вопрос скорее философский, чем практический.

У меня нет времени писать подробно, но вот мои пять копеек. Хотя я согласен с тем, что вы хотите ограничить количество запросов на получение и установку, потому что класс должен скрывать свои внутренние компоненты, вам также необходимо учитывать, что Java и PHP — это разные инструменты и разные цели. В веб-среде ваши классы создаются и удаляются с каждым запросом, поэтому код, который вы пишете, не должен зависеть от огромных классов. В статье, на которую вы указали, автор предлагает разместить логику представления в классе. Это, вероятно, не имеет смысла в Интернете, поскольку я, вероятно, захочу представить представление в нескольких форматах (rss, html и т. д.). Таким образом, использование методов доступа (get & set) является неизбежным злом. Вы все еще хотите использовать их вдумчиво, чтобы не выстрелить себе в ногу. Суть в том, чтобы ваши классы выполняли работу за вас, а не заставляли их выполнять работу извне. Получая доступ к своим свойствам с помощью метода, а не напрямую, вы скрываете внутренности, которые вам нужны.

Опять же, в этом посте можно было бы использовать несколько примеров, но сейчас у меня нет времени.

Может ли кто-нибудь еще привести несколько примеров того, почему методы доступа не являются злом?

Здесь есть два подхода: то, что я называю подходом «скажи, а не спрашивай», и другой подход — подход ViewModel/DTO. По сути, вопросы вращаются вокруг того, что, по вашему мнению, является «моделью». Скажи, не спрашивай, требует, чтобы единственный способ, которым объект может быть экстернализован, исходил от самого объекта. Другими словами, для рендеринга объекта у вас будет метод рендеринга, но этот метод рендеринга должен будет взаимодействовать с интерфейсом. Что-то вроде этого:

class DomainObject {
   ....
   public function render(DomainObjectRenderer $renderer) {
        return $renderer->renderDomainObject(array $thegorydetails);
   }
}

В контексте Zend Framework вы можете создать подкласс Zend_View, и ваш подкласс реализует этот интерфейс.

Я делал это раньше, но это немного громоздко.

Второй вариант — преобразовать вашу доменную модель в объект ViewModel, который похож на упрощенное, сглаженное, «растянутое» представление ваших данных, настроенное для каждого конкретного представления (с одной ViewModel на представление), и на обратном пути. , преобразуйте данные POST в EditModel.

Это очень популярный шаблон в мире ASP.NET MVC, но он также похож на шаблон класса «DTO», используемый для передачи данных между «слоями» в приложении. Вам нужно будет создать картографы, чтобы сделать за вас грязную работу (на самом деле мало чем отличается от DataMapper). В PHP 5.3 вы можете использовать отражение для изменения частных свойств, поэтому вашему DomainObject даже не нужно раскрывать себя!

На мой взгляд, реализация геттеров и сеттеров имеет два преимущества:

1. Вы можете выбрать, какие свойства сделать общедоступными, поэтому вам не обязательно раскрывать все внутренности модели.
2. Если вы используете IDE с автозаполнением, все доступные свойства будут на расстоянии клавиши TAB, когда вы начнете вводить «получить» или «установить» — одного этого для меня достаточно.