Оба подхода работоспособны. Кому-то приятен AR с CRUD своей простотой для программиста, кому-то - Domain Model с Task Based UI своим удобством для клиента. Смысл об этом спорить?
Мы здесь говорим именно про извращённые попытки "вкостылить" готовую специфическую базу в Doctrine вместо Eloquent. Про использование Doctrine не по назначению как AR над готовой базой.
А чего тогда столько неприязни к DBFirst и Yii? А то что БД в DBFirst на основе предметной области а не из вакуума формируется надеюсь отрицать не будете?
Простите, а где такое назначение задекларировано? Что-то не слышал, что Doctrine на готовую базу это "костыли".
Ну и Вы не будете отрицать, что формирование классов порой сильно отличается от формирования таблиц. Я показал пример, когда в БД придумывается одна таблица, а в коде это уже не один класс, а целый агрегат из восьми классов. И агрегат может содержать динамические стратегии и прочую нетривиальную логику, о которой при формировании БД думать сложно.
Чистый AR - это класс, привязанный к таблице БД, где поля и связи объекта один-в-один совпадают с полями в БД и расположены в корне. Как только структура класса перестаёт совпадать со структурой таблицы, сразу прямая привязка к полям начинает мешать и возникает необходимость ручного маппинга в afterFind/beforeSave.
Task Based UI - это про проектирование операций по предметной области.
Взять хотя бы тот факт, что она сама генерирует миграции по сущностям, а не сущности по БД. В документации Symfony приведён пример. Просто пишем классы, а потом по ним генерируем миграции через migration:diff. Это удобно. Не нужно сочинять миграции вручную. Ну и год назад автор об этом сказал, когда выпилил обратную генерацию сущности по маппингу.
Здесь человек хочет вставить свою базу с составным FK не на PK. Естественно, что тратит кучу времени и огребает "костылей" вроде возни с JoinColumns для своих задач.
Какие-то по меньшей мере странные препятствия вы привели. Меня это не нервирует и ничего менять я не боюсь. Это нормальный рабочий процесс. Базу я проектирую не спонтанно а опираясь на юзкейсы и примерный перечень запросов. И код можно получить нормальный. Никаких анемичных сущностей или лапши.ElisDN писал(а): ↑2018.03.15, 13:09
В общем, пока не начнёшь программировать код, сразу не догадаешься, что тебе завтра вдруг потребуется от БД. Всё время придётся либо править базу, либо всё время подгонять свой код под существующую БД. А это нервирует.
В DB-First таблицы придумываются спонтанно:
1. Прочитали ТЗ
2. Построили предполагаемую структуру таблиц
3. Навесили AR на таблицы
4. Находим несоответствия кода и таблицы
5. Пишем миграцию под каждую правку
6. Боимся переписывать классы из-за страха сломать базу
7. Боимся переименовывать поля из-за страха сломать базу
Свобода не полная. ООП гораздо гибче чем БД. Что угодно и как угодно на базу не спроецируется. Все равно придется на нее оглядываться. Samdark и я уже об этом упоминали ранее в этой теме.
Я не согласен с таким определением AR. Вот первоисточник https://www.martinfowler.com/eaaCatalog ... ecord.html. Там дело не в "один к одному" и плоском AR, а в "putting data access logic in the domain object.". Можно делать вложенные объекты, можно к нескольким таблицам обращаться. Фаулер этого не запрещает. В Yii тоже никто не мешает так делать.ElisDN писал(а): ↑2018.03.15, 13:09
Чистый AR - это класс, привязанный к таблице БД, где поля и связи объекта один-в-один совпадают с полями в БД и расположены в корне. Как только структура класса перестаёт совпадать со структурой таблицы, сразу прямая привязка к полям начинает мешать и возникает необходимость ручного маппинга в afterFind/beforeSave.
Вам удобно всё делать с базой. Мне удобнее придумывать классы без базы, так как "ООП гораздо гибче чем БД". Всем хорошо. Тогда о чём спор?anton_z писал(а): ↑2018.03.15, 13:46 Какие-то по меньшей мере странные препятствия вы привели. Меня это не нервирует и ничего менять я не боюсь. Это нормальный рабочий процесс. Базу я проектирую не спонтанно а опираясь на юзкейсы и примерный перечень запросов. И код можно получить нормальный. Никаких анемичных сущностей или лапши.
Чаще только в Read Model требуются хитроумные JOIN-ы. А в Domain Model всё проецируется без проблем.
Потому, что бизнес-логику сущностей для юзкейсов проектируют и проверяют как раз тестами по TDD. Для этого они и придуманы. И в этом как раз плюсы первоначального продумывания логики в коде, когда база не мешает придумывать архитектуру.
Да, никто не мешает. Но практически никто в AR так не делает.anton_z писал(а): ↑2018.03.15, 13:46 Я не согласен с таким определением AR. Вот первоисточник. Там дело не в "один к одному" и плоском AR, а в "putting data access logic in the domain object.". Можно делать вложенные объекты, можно к нескольким таблицам обращаться. Фаулер этого не запрещает. В Yii тоже никто не мешает так делать.
Нравится тем, кому важнее код, тесты и чистые классы. Кому коллекции и вложенные объекты нужны "из коробки". Не нравится тем, кто привык к PhpMyAdmin и ActiveRecord. Всё нормально.
Процитируйте моё предложение с негативом.
Да, этот спор можно закончить. Я понял вас, а вы меня.
Из того что я видел:
ElisDN писал(а):
Yii - любительский, монолитный, самозамкнутый, простой для новичков RAD-фреймворк. Кастомизируется чаще костылями. Но код у новичков выходит так себе. viewtopic.php?f=12&t=42383&p=209785&hil ... ый#p209785
Наоборот. Вместо исправно работающего и проверенного годами Symfony Вы пытаетесь начать большой проект на попсовом Yii. viewtopic.php?f=12&t=42383&p=209785&hil ... B9#p209806
Кому нужно "дорого и классно" (чтобы вырастить хороший проект), те сразу выбирают профессиональный фреймворк, читают книги и нанимают дорогих разработчиков. А кому нужно "быстро и дёшево" (чтобы сэкономить или просто поиграться) выбирают Доширак, дермантин, индусов, лапшекод и прочий фастфуд. Так получилось, что фастфуд быстрее и удобнее делать на Yii.viewtopic.php?f=13&t=40623&p=209063&hil ... B9#p209063
ElisDN писал(а): ↑2018.03.09, 00:06 Вот это и есть ключевой момент. Вам может и покажется странным, но Doctrine - это как раз вещь для подхода Code-First вместо DB-First, который Вы из-за непонимания называете "тупизмом". Когда сначала программируют сущности без БД, а лишь потом генерируют базу для их сохранения. А не наоборот вкостыливают готовую БД во фреймворк, как Вы хотите.
Какая злая ирония у вас. Ладно бы просто о проблемах говорили. Так вы еще издеваетесь. И это только начало. Вам в этой теме много раз пытались объяснить - не нравится, не пользуйся, что говорить. Но вы продолжаете одно и тоже в разных темах по нескольку раз. Причем мы с вами убедились, что подход Yii рабочий и к плохому коду сам по себе не приводит. Вы называете фреймворк "непрофессиональным", "любительским", "попсовым". Опустили всех ниже плинтуса. На нем много людей в отрасли работает. Они все "непрофессионалы"?ElisDN писал(а): ↑2017.09.01, 08:14 Тогда зайдите на http://yiiframework.ru и замените тексты на "Yii - это быстрый некомпонентный монолитный PSR-несовместимый фреймворк с сильной связанностью для бырой запилки крудов без повторного использования кода вне фреймворка, иногда позволяющий писать чистый гибкий код на свой страх и риск". Тогда и хейтить перестанут
супер, буду кодить сайты на плюсах, и доказывать что это норм подход, а кто против - "не нравится, не пользуйтесь"anton_z писал(а): ↑не нравится, не пользуйся, что говорить.
что в вашем представлении "нормальный проект", и что такое "обычная веб-разработка" ?anton_z писал(а): ↑В умелых руках быстро пишутся нормальные проекты. Для обычной веб-разработки за глаза хватит.
именно это я и сказал выше, собственно дискутировать с данной группой людей бесполезно. логика у них отсутствует, посмотри как они то одно говорят то другое, но они тех кто с ними не согласен - называют фанатиками...anton_z писал(а): ↑2018.03.14, 02:39Да тут не в этом дело. По мне какое-то странное разделение на CodeFirst и DBFirst, как на белое и черное. Причем DBFirst характеризуется как "вкостыливание". В связи с этим возникают вопросы:
Когда сначала БД разрабатывают, что на предметную область не опираются? Что не читают юзкейсов и требований? Не выделяют сущности? Как ее вообще тогда разрабатывают? Структура БД это одна из реализаций модели предметной области, с помощью инструментария БД, а не ЯП. Во многих случаях действительно проще начинать с БД. К плохому качеству кода приложения, которое будет затем написано и будет работать с этой БД (анемия/спагетти и пр.) это само по себе никак привести не может.
Почему я считаю, что в некоторых случаях начинать с БД правильнее и проще (Рассматриваю сайты с БД). При разработке приложений, а тем более при гибкой разработке, очень важно сначала устранить максимальные риски, чтобы впоследствии избежать большого рефакторинга и срыва сроков. БД, как инструмент менее гибкий, чем ЯП и сильно влияющий на производительность системы в целом, можно определить как вносящий больший риск. На ЯП (без оглядки на возможности БД) можно такого понаделать, ни на одну базу потом не спроецируется или будет недотягивать до требуемой производительности - придется рефакторить код и иногда немало кода - а это время/деньги. Поэтому начинать разработку с БД так популярно, это работает. И никакого "вкостыливания" тут нет.
sm-vasya писал(а): ↑2018.03.09, 12:29ElisDN писал(а): ↑2018.03.09, 00:06Вот это и есть ключевой момент. Вам может и покажется странным, но Doctrine - это как раз вещь для подхода Code-First вместо DB-First, который Вы из-за непонимания называете "тупизмом". Когда сначала программируют сущности без БД, а лишь потом генерируют базу для их сохранения. А не наоборот вкостыливают готовую БД во фреймворк, как Вы хотите.
очевидно что 14 лет в профессии прошли для вас даром, потому что в жизни и в деятельности бывает всякое, а вы со своим коде-фёст.....
если у вас так получается - это не значит что все другие тупые идиотыElisDN писал(а): ↑2018.03.15, 13:09 Ну и Вы не будете отрицать, что формирование классов порой сильно отличается от формирования таблиц. Я показал пример, когда в БД придумывается одна таблица, а в коде это уже не один класс, а целый агрегат из восьми классов. И агрегат может содержать динамические стратегии и прочую нетривиальную логику, о которой при формировании БД думать сложно.
В общем, пока не начнёшь программировать код, сразу не догадаешься, что тебе завтра вдруг потребуется от БД. Всё время придётся либо править базу, либо всё время подгонять свой код под существующую БД. А это нервирует.
В DB-First таблицы придумываются спонтанно:
1. Прочитали ТЗ
2. Построили предполагаемую структуру таблиц
3. Навесили AR на таблицы
4. Находим несоответствия кода и таблицы
5. Пишем миграцию под каждую правку
6. Боимся переписывать классы из-за страха сломать базу
7. Боимся переименовывать поля из-за страха сломать базу
а кто вам сказал что это хороший БД-шник и АПИ-шнег ? в принципе не важно что дать обезъяне - гранату или автомат ...
эммм..... даже слов нет... давайте я вам за небольшую плату - найду кучу такого же говнокода на симфони и доктрине , и чо ?ElisDN писал(а): ↑2018.03.14, 22:23Код: Выделить всё
if ($model->status === Model::STATUS_APPROVED && !empty($model->owner_phone_code) && !empty(...)) { ... }
samdark писал(а): ↑2018.03.14, 14:27 У db first есть ещё и плюс (если система относительно детерминирована) — оптимальные типы данных и структура БД в общем.
При code first часто наблюдал не совсем оптимальные типы, отсутствие индексов, 100500 запросов вместо пары JOIN-ов и так далее. "Высокоуровневый код — главное, как оно будет хранится и выбираться на низком уровне — пофиг".
Абстракции текут. Если у вас не одна база, а 15 разных на разных серверах, вероятно это вылезет почти на самый верхний уровень. Сделать не протекающую частенько слишком дорого. Либо это аукнется дублированием данных, либо не использованием возможностей реляционных баз (а зачем они нам тогда?), либо ещё чем-то таким.
самое интересное - что я видел кучу глюкалова на "професиональном" симфони которые пилят кучу времени такие же вот "професионалы" и кучу симпатичных и больших проектов на "непрофесиональном" Юии
Несогласен я с таким разделением. Ни к чему я не привык. Я открыт для новых вещей. Yii мне нравится осознанно. Мне нравится чистый код, тесты, архитектура и при этом ActiveRecord, Service Locator и Yii. Разве так нельзя?
Под нормальный проектом имел ввиду проекты, которые создаются и развиваются (с точки зраения разработки) без тяжелых для преодоления проблем и больших объемов рефакторинга приближающихся к полному переписыванию.
Я ElisDN так понял - ему нравится чистый код, абстракция DomainModel от всего, DDD, CodeFirst.
да, он фашист, понятия путает, а виноваты все кроме него
Плохой код можно написать везде.sm-vasya писал(а): ↑2018.03.16, 00:17а кто вам сказал что это хороший БД-шник и АПИ-шнег ? в принципе не важно что дать обезъяне - гранату или автомат ...
эммм..... даже слов нет... давайте я вам за небольшую плату - найду кучу такого же говнокода на симфони и доктрине , и чо ?ElisDN писал(а): ↑2018.03.14, 22:23Код: Выделить всё
if ($model->status === Model::STATUS_APPROVED && !empty($model->owner_phone_code) && !empty(...)) { ... }
