anton_z писал(а): ↑2018.03.15, 09:54
А то что БД в DBFirst на основе предметной области а не из вакуума формируется надеюсь отрицать не будете?
Ну и Вы не будете отрицать, что формирование классов порой сильно отличается от формирования таблиц. Я показал пример, когда в БД придумывается одна таблица, а в коде это уже не один класс, а целый агрегат из восьми классов. И агрегат может содержать динамические стратегии и прочую нетривиальную логику, о которой при формировании БД думать сложно.
В общем, пока не начнёшь программировать код, сразу не догадаешься, что тебе завтра вдруг потребуется от БД. Всё время придётся либо править базу, либо всё время подгонять свой код под существующую БД. А это нервирует.
В DB-First таблицы придумываются спонтанно:
1. Прочитали ТЗ
2. Построили предполагаемую структуру таблиц
3. Навесили AR на таблицы
4. Находим несоответствия кода и таблицы
5. Пишем миграцию под каждую правку
6. Боимся переписывать классы из-за страха сломать базу
7. Боимся переименовывать поля из-за страха сломать базу
В Code-First же сущности и логика спокойно продумываются и совершенствуются по TDD:
1. Написали заготовки тестов по ТЗ
2. Набросали содержимое тестов
3. Спрограммировали черновик класса под тесты
4. Отрефакторили агрегат
5. Перекомпоновали ответственности
6. Получили более-менее удобный и рабочий код
7. Проверили сайт на репозиториях-заглушках с serialize/unserialize объектов в файлы
8. Выбрали подходящую БД
9. Сгенерировали миграции
Это чисто психологическая разница: либо есть какие-либо ограничения, либо полная свобода действий. А с AR даже тест написать не получится, не создав заранее таблицы. В итоге вместо правки классов полдня правим миграции или моки схемы.
anton_z писал(а): ↑2018.03.15, 09:54
Я не согласен с разделением AR - DomainModel. На AR можно и не только CRUD приложения писать. С этим тоже будете спорить?
Domain Model можно на AR построить. Да, не будет изоляции от базы, но она далеко не всегда и нужна.
Чистый AR - это класс, привязанный к таблице БД, где поля и связи объекта один-в-один совпадают с полями в БД и расположены в корне. Как только структура класса перестаёт совпадать со структурой таблицы, сразу прямая привязка к полям начинает мешать и возникает необходимость ручного маппинга в afterFind/beforeSave.
anton_z писал(а): ↑2018.03.15, 09:54
UI тут вообще причем?
Task Based UI - это про проектирование операций по предметной области.
anton_z писал(а): ↑2018.03.15, 09:54
Простите, а где такое назначение задекларировано?
Взять хотя бы тот факт, что она сама генерирует миграции по сущностям, а не сущности по БД. В
документации Symfony приведён пример. Просто пишем классы, а потом по ним генерируем миграции через migration:diff. Это удобно. Не нужно сочинять миграции вручную. Ну и год назад
автор об этом сказал, когда выпилил обратную генерацию сущности по маппингу.
anton_z писал(а): ↑2018.03.15, 09:54
Что-то не слышал, что Doctrine на готовую базу это "костыли".
Здесь человек хочет вставить свою базу с составным FK не на PK. Естественно, что тратит кучу времени и огребает "костылей" вроде возни с
JoinColumns для своих задач.