Какая плюс сторона аннотаций для описания сущности в Doctrine2?
В Doctrine1 и Propel (который я использовал много раз) обратное проектирование базы данных для создания yml или xml, тогда генерация модели - очень быстрый рабочий процесс.
В Doctrine2, выбирая аннотации, нужно написать большое количество кода плиты котла, чтобы получить объекты на месте. но аннотации, похоже, являются "способом идти".
Что мне не хватает?
Рабочий процесс, который вы описываете с D1 и propel, в точности противоположно предпочитаемому способу мышления для Doctrine2. Фактически, я также избегал писать свои собственные определения баз данных в D1, в основном по тем же причинам, которые я приводил здесь:
В Доктрине 2 вас беспокоят прежде всего ваши сущности. Объекты - это просто простой PHP-объект, и доктрина просто управляет вашей персистентностью. Тот факт, что Doctrine находится за кулисами, сбрасывая данные в какой-либо базе данных, является практически запоздалой мыслью. Весь этот беспорядок - это именно то, что вы должны абстрагироваться! В теории вы могли бы избавиться от доктрины в какой-то будущей дате и написать свою собственную логику персистентности. Ваши объекты будут работать так же, как и всегда.
Глядя на это так, начиная с схемы базы данных, это просто глупо. Вас больше интересуют ваши сущности и бизнес-логика, встроенные в них и вокруг них. Этот вкусный суп!
Теперь, поскольку вы используете доктрину для сохранения ваших сущностей, она (вероятно) имеет смысл хранить данные сопоставления прямо там с определениями классов.
Итак, ваш новый рабочий процесс:
./doctrine orm:schema:create и пусть доктрина беспокоится о
определения таблиц базы данных.Теперь, если у вас есть некоторая устаревшая база данных, все становится сложнее и намного менее забавно. Я не рассматривал этот сценарий с D2, но я думаю, что это уродливо.
Что касается кода Boilerplate: Я вижу, что люди жалуются на то, что нужно писать геттеры/сеттеры для своих объектов. Я делаю что-то подобное что делает этот парень - все мои сущности расширяют класс AbstractEntity, который использует магические методы для генерации getters/seters для любых свойств, которые не имеют ручной работы из них. Как только вы это сделаете, практически нет котельной плиты.
В качестве альтернативы, в наши дни есть много инструментов, которые вычеркнут шаблон для вас (PHPStorm делает это, плагины для Sublime и т.д.). Это делает котельную пластину довольно безболезненной и имеет дополнительное преимущество, заключающееся в том, что вы можете добавлять подсказки типа, и ваш редактор может обеспечить удобное автозаполнение.
Основная причина, по которой я использую аннотации для yml или xml, - это простота настройки. Мне не нужно искать в другом файле, чтобы помнить (например), что я установил имя таблицы соединений, как в отношении ManyToMany. И если я что-то меняю в объекте домена (что происходит очень рано в моем процессе разработки), мне также не нужно забывать обновлять другой файл конфигурации с изменениями.
Однако, как вы сказали, схема базы данных более легко переносится в один из других конфигурационных форматов, поэтому в подобных ситуациях вам может быть лучше использовать yml или xml вместо аннотаций. В конце концов все сводится к личным предпочтениям... используйте то, с чем вам больше всего нравится.