QueryBuilder и AR в отдельном пакете?

Не относящиеся к фреймворку и программированию вопросы
anton_z
Сообщения: 457
Зарегистрирован: 2017.01.15, 15:01

Re: QueryBuilder и AR в отдельном пакете?

Сообщение anton_z » 2019.08.07, 13:46

ElisDN писал(а):
2019.08.07, 13:18

Я как раз за спокойную эволюцию по пути выпуска микрорелизов с постепенным своевременным обсуждением, рефакторингом, разделением и внедрением. Например:
  • в 2.1 вынести виджеты
  • в 2.2 выделить интерфейсы
  • в 2.3 вынести ActiveRecord
  • в 2.4 добавить опциональный PSR-7 и RequestHandlerWrapperController для PSR-15 RequestHandler
  • в 3.0 вычистить все @deprecated, переработать flow, добавив Pipeline для Middleware
  • в 3.1 ...
А вышел опять антикейс "просидим пять лет на 2.0, а потом с бухты-барахты перепишем вообще всё в 3.0, вообще выбросив AR".
Здравые рассуждения. Согласен.

thenotsoft
Сообщения: 12
Зарегистрирован: 2019.07.03, 10:13

Re: QueryBuilder и AR в отдельном пакете?

Сообщение thenotsoft » 2019.08.07, 15:28

anton_z писал(а):
2019.08.07, 13:46
ElisDN писал(а):
2019.08.07, 13:18

Я как раз за спокойную эволюцию по пути выпуска микрорелизов с постепенным своевременным обсуждением, рефакторингом, разделением и внедрением. Например:
  • в 2.1 вынести виджеты
  • в 2.2 выделить интерфейсы
  • в 2.3 вынести ActiveRecord
  • в 2.4 добавить опциональный PSR-7 и RequestHandlerWrapperController для PSR-15 RequestHandler
  • в 3.0 вычистить все @deprecated, переработать flow, добавив Pipeline для Middleware
  • в 3.1 ...
А вышел опять антикейс "просидим пять лет на 2.0, а потом с бухты-барахты перепишем вообще всё в 3.0, вообще выбросив AR".
Здравые рассуждения. Согласен.
согласен, по текущей активности развития, релиз будет в лучшем случае через год, если не 2, opencollective как то активности не прибавил, но время покажет, надеюсь ошибаюсь.

myks1992@mail.ru
Сообщения: 137
Зарегистрирован: 2017.11.15, 23:54

Re: QueryBuilder и AR в отдельном пакете?

Сообщение myks1992@mail.ru » 2019.08.08, 05:33

Естественно, что при хороших знаниях Фреймворк особо неважен. Однако на Yii больше непонятностей в коде у разработчиков, чем на этом же Larevel.

Я не буду бороться за AR или Doctrine. Я даже соглашусь, что для большинства нужна AR. Так как много проектов, которые на уровне блога. Им просто нужен быстрый прототип.

Хочется лишь повысить немного порог входа на Yii и показать хорошие практики. Этого очень не хватает. Хотя бы переиспользуемость. В добавок более частые релизы минорных версий.

AR стоит оставить дополнительным пакетом, как писал выше. И уже сам разработчик выбирает как лучше строить и из чего.

В этом вопросе не найти правых. Команда фреймворка все решит. Всем не угодить. А вот уже эти решения и покажут на деле на сколько обдуманно подходила команда к разработке. Тогда будет ясно заживет ли Фреймворк новой жизнью.

anton_z
Сообщения: 457
Зарегистрирован: 2017.01.15, 15:01

Re: QueryBuilder и AR в отдельном пакете?

Сообщение anton_z » 2019.08.08, 05:47

myks1992@mail.ru писал(а):
2019.08.08, 05:33


Я не буду бороться за AR или Doctrine. Я даже соглашусь, что для большинства нужна AR. Так как много проектов, которые на уровне блога. Им просто нужен быстрый прототип.
А я считаю, что это заблуждение, использование DataMapper или AR никак не влияет на расширяемость проекта, его размеры. И с AR можно объемные проекты делать.

myks1992@mail.ru
Сообщения: 137
Зарегистрирован: 2017.11.15, 23:54

Re: QueryBuilder и AR в отдельном пакете?

Сообщение myks1992@mail.ru » 2019.08.08, 06:01

anton_z писал(а):
2019.08.08, 05:47
myks1992@mail.ru писал(а):
2019.08.08, 05:33


Я не буду бороться за AR или Doctrine. Я даже соглашусь, что для большинства нужна AR. Так как много проектов, которые на уровне блога. Им просто нужен быстрый прототип.
А я считаю, что это заблуждение, использование DataMapper или AR никак не влияет на расширяемость проекта, его размеры. И с AR можно объемные проекты делать.
Я и говорю, что зависит от знаний и подходов)) Знаю, что есть много хороших проектов на Yii. Этот же DNS. Говорю лишь о том, что не все пользуются правильно этим удобным партерном. Так как базовых пониманий нет. А кто-то вообще изучение программирования начинает с этого фреймворка. Из-за этого на форуме много вопросов, ответы которых написаны в документации. Поэтому сложности, чаще всего, увеличивают порог входа и осмысливания.

Я ещё раз повторюсь, что моя дискуссия направлена не на профессионалов и понимающих. Суть в том, что не каждый новичок быстро поймёт как работать с доктриной. А вот на сейчас Yii2 можно без знаний, без миграций нагенировать код по таблицам и уже «программист»))

PS важно не доказать кто прав, а показать общий настрой аудитории, высказать своё мнение.

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение BrusSENS » 2019.08.08, 08:43

ElisDN писал(а):
2019.08.07, 13:18
Наблюдаемый сейчас резкий переход к DataMapper или куда-то ещё - это и есть революционный хаос, который вам и мне не нравится.
DataMapper вообще считаю паттерном, который готовит каждый сам, исходя из своих специфичных требований, предъявляемых к конкретному проекту.
ElisDN писал(а):
2019.08.07, 13:18
Я как раз за спокойную эволюцию по пути выпуска микрорелизов с постепенным своевременным обсуждением, рефакторингом, разделением и внедрением. Например:
  • в 2.1 вынести виджеты
  • в 2.2 выделить интерфейсы
  • в 2.3 вынести ActiveRecord
  • в 2.4 добавить опциональный PSR-7 и RequestHandlerWrapperController для PSR-15 RequestHandler
  • в 3.0 вычистить все @deprecated, переработать flow, добавив Pipeline для Middleware
  • в 3.1 ...
А вышел опять антикейс "просидим пять лет на 2.0, а потом с бухты-барахты перепишем вообще всё в 3.0, вообще выбросив AR".
Именно. Считаю минорные релизы лучшим решением в виду сегодняшнего развития фреймворков. Но почему-то вместо этого начинается запил "симфонидва", который предназначен для абсолютно других проектов. Yii потеряет свою нишу таким образом. Что самое интересное, так это то, что ещё не вышел мажорный релиз, а стабильную ветку заморозили в развитии, принимая только исправления. Абсурд.

В итоге выкинув AR, который, к слову, приятен для соответствующих проектов, пропадает смысл использования Yii, т.к. тот же слим можно прекрасно использовать с тем же eloquent. Так что страшно от того, что же будет дальше.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение BrusSENS » 2019.08.08, 09:19

myks1992@mail.ru писал(а):
2019.07.30, 11:34
Как то вы очень негативно настроены против DataMapper. Тогда почему, интересно, его используют на крупных проектах и передовых фреймворках вроде Symfony?) AR, как паттер не плохой. Мне он тоже нравится для простых задач вроде CRUD. Если разработка сложнее чем CRUD — нарушается паттерн единой ответственности .
Вот я смотрю на то, что пишут адепты DDD и "TRUE Architect" (я так привык называть данное заболевание), начитавшиеся умных статей бородатых дядей-теоретиков и диву даюсь. Вы вообще понимаете то, что по сути при работе с проектом у Вас должны быть слои для работы с бд и слой с бизнес логикой? А теперь расскажите мне о том, какие ещё операции, отличные от Insert (Create), Select (Read), Update и Delete существуют? Правильно, никаких. Посему операции с хранилищем всегда будут CRUD, что AR и DM делают. Другой момент в том, что нарушается SOLID. Но SOLID можно нарушать, если ты понимаешь, что делаешь и цену этому и ничего плохого тут нет.

Едем дальше.
myks1992@mail.ru писал(а):
2019.07.30, 11:34
Как всем известно что одна модель отвечает за сущность, за валидацию, за отображение данных, за сохранение в базу и умудряются ей ещё сохранять Файлы и осуществлять переводы. Поэтому он сложный в больших проектах. Но на старте хорош.
Это видимо известно только Вам. AR отвечает только за работу с данными и всё. Остальные свистоперделки - это то, что следовало бы выкинуть из AR. В AR не должно быть логики отображения данных и их валидации. И использование в больших проектах не более, чем вопрос вкуса и правильного использования. DM тоже не сахар, далеко не сахар. А если у Вас работа с AR заключалась в работе по мануалам, то это Ваше допущение. Работаю AR + сервисный слой + Отдельные классы форм (Model) с композицией (привет elisdn/yii2-composite-form) и всё прекрасно работает и всё расширяемо. И используется далеко не на старте.
myks1992@mail.ru писал(а):
2019.07.30, 11:34
Поэтому, DataMapper, наверное, имеет какие-то недостатки, но это лучше, чем зарыться в своём же коде. Зато он позволяет разделить всё по своим ответственностям на слоистую архитектуру. При этом позволяет работать с малым использованием функционала не создавая свои репозитории.
Ну вот опять. Вы не понимаете смысл данного паттерна, а рассуждаете. DM - паттерн, абстрагирующий работу с хранилищем на уровне сущностей, а Repository - паттерн, абстрагирующий логику для работы с хранилищем для агрегата. У DM, по сути, нет никакой ответственности, кроме совершения CRUD операций и гидрации, понимаете? AR делает то же самое.
myks1992@mail.ru писал(а):
2019.07.30, 11:34
Кроме того вам не мешает никто использовать ваш совершенный SQL запрос вместо DataMapper) Но вы сами сказали как было проблемно реализовать работу с файлами. Вот так же вам будет проблемно перевести сущности из СУБД обратно в Файлы. Или вам потребуется сделать «плоскую базу» и тут вы уже тоже сломаете свой проект. Как вы будете тестировать в таком случае?)
Кхм. Шта? Сущности из СУБД? Вы реально умничаете, не понимая, о чём говорите. Какие сущности в СУБД?! Субд хранит наборы данных и никаких сущностей там нет. Если у Вас база может поломать проект на тестах, то у меня для Вас плохие новости...

Вообще для Вас отдельно советую почитать банду и советую книжку от Зандстры об основах ООП. Там прочитаете предостережение о том, что паттерны используются "исключительно для решения определённых проблем", а никак не для того, что бы они были. Данная болезнь называется "Паттернизмом".
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
samdark
Администратор
Сообщения: 9251
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение samdark » 2019.08.08, 13:31

Оффтопим, конечно, но, думаю, стоит пояснить.

Минорными релизами не получилось поправить вещи, которые составляли самую основу Yii 2:

1. Компоненты с магическими property.
2. Развесистое дерево наследования.
3. Концептуальную несовместимость со многими PSR.
4. Концептуальную завязанность на service locator.

Поэтому вместо 2.1 у нас 3.0. Изначальный план был с минорными релизами, но не вышло.

На тему заморозки фич 2.0. Заморожено только ядро. Extension-ы развиваются. Втащить и то и другое мы просто не можем. Если вдруг придёт несколько человек, готовых серьёзно развивать 2.0 и, для начала, отсмотрит все issue и pull request, то мы подумаем на тему разморозки.

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение BrusSENS » 2019.08.08, 15:42

samdark писал(а):
2019.08.08, 13:31
Оффтопим, конечно, но, думаю, стоит пояснить.

Минорными релизами не получилось поправить вещи, которые составляли самую основу Yii 2:

1. Компоненты с магическими property.
2. Развесистое дерево наследования.
3. Концептуальную несовместимость со многими PSR.
4. Концептуальную завязанность на service locator.

Поэтому вместо 2.1 у нас 3.0. Изначальный план был с минорными релизами, но не вышло.

На тему заморозки фич 2.0. Заморожено только ядро. Extension-ы развиваются. Втащить и то и другое мы просто не можем. Если вдруг придёт несколько человек, готовых серьёзно развивать 2.0 и, для начала, отсмотрит все issue и pull request, то мы подумаем на тему разморозки.
Лично я не лезу в кишки Yii со своими предложениями, т.к. считаю, что у меня и у Core разработчиков разный уровень, хотя большую часть классов Yii2 знаю почти наизусть. Хотя посмотреть конечно стоит. В любом случае 2 ветке ничего уже не будет и можно дать сообществу попробовать развивать второй мажор дальше, от этого хуже явно не будет.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

anton_z
Сообщения: 457
Зарегистрирован: 2017.01.15, 15:01

Re: QueryBuilder и AR в отдельном пакете?

Сообщение anton_z » 2019.08.09, 02:51

BrusSENS писал(а):
2019.08.08, 09:19
Если у Вас база может поломать проект на тестах, то у меня для Вас плохие новости...
А что плохого в том что база может поломать тесты? По-моему так это наоборот хорошо, если тесты упадут по причине того, что не соблюдено ограничение внешнего ключа, например.

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение BrusSENS » 2019.08.09, 15:46

anton_z писал(а):
2019.08.09, 02:51
А что плохого в том что база может поломать тесты? По-моему так это наоборот хорошо, если тесты упадут по причине того, что не соблюдено ограничение внешнего ключа, например.
Не не, плохого ничего нет, но вот для человека, которому ответ был адресован - плохое есть. Он желает не зависеть от бд, но ему в этом мешает AR. Я просто не понимаю, как AR делает невозможным тестирование. Подкинули SQLite и вперёд, в чём проблема то? То, что SQLite ничего нет страшного, т.к. по сути используется только для тестирования. Или я не так понял и человек тестирует интерфейсы DM'ов?
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
ElisDN
Сообщения: 5468
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение ElisDN » 2019.08.09, 17:12

BrusSENS писал(а):
2019.08.09, 15:46
Я просто не понимаю, как AR делает невозможным тестирование.
Не "делает невозможным тестирование", а "делает невозможным юнит-тестирование без базы".

База замедляет тесты и добавляет лишний геморрой с фикстурами.
BrusSENS писал(а):
2019.08.09, 15:46
Подкинули SQLite и вперёд, в чём проблема то?
В несовместимости SQLite и PostgreSQL.

skynin
Сообщения: 207
Зарегистрирован: 2017.12.12, 10:09

Re: QueryBuilder и AR в отдельном пакете?

Сообщение skynin » 2019.08.09, 17:38

ElisDN писал(а):
2019.08.09, 17:12
База замедляет тесты и добавляет лишний геморрой с фикстурами.
Да, замедляет, есть такая проблемка

А насчет фикстур, то дело в подходе
У нас например фикстуры готовят тестировщики, в гугл таблицах.
В которых описывают много таблиц и связей между ними, в удобной для человека форме (то есть не со всеми полями в БД, а то и в фиктивных полях)

Потом таблицы экспортируются в csv, и специальный конфигуремый загрузчик фикстур закидывает их в базу
ElisDN писал(а):
2019.08.09, 17:12
В несовместимости SQLite и PostgreSQL.
Если PostgreSQL, то проект серьезный.
А если серьезный - то наверняка часть бизнес логики утекает в ХП
и как тестировать тогда без работы с базой?

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

Аватара пользователя
ElisDN
Сообщения: 5468
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение ElisDN » 2019.08.09, 17:58

skynin писал(а):
2019.08.09, 17:38
А насчет фикстур, то дело в подходе
У нас например фикстуры готовят тестировщики, в гугл таблицах.
В которых описывают много таблиц и связей между ними, в удобной для человека форме (то есть не со всеми полями в БД, а то и в фиктивных полях)
Да, для интеграционных тестов все используют и заполняют фикстуры. Это понятно. Но вот зачем для юнит-тестов горы фикстур юзать? Или вы отдельные юнит-тесты не пишете?
skynin писал(а):
2019.08.09, 17:38
Если PostgreSQL, то проект серьезный.
А если серьезный - то наверняка часть бизнес логики утекает в ХП
и как тестировать тогда без работы с базой?
Да хоть MySQL. Всё равно есть отличия в возможностях и типах и без ХП.
skynin писал(а):
2019.08.09, 17:38
И, второй момент
выбирать архитектуру потому что для нее тесты будут быстро выполняться, ну... это как-то странно.
Выбирать для того, чтоб голова от мешанины не взорвалась.
skynin писал(а):
2019.08.09, 17:38
Есть много технических и административных способов улучшить жизнь с медленными тестами.
Например?

skynin
Сообщения: 207
Зарегистрирован: 2017.12.12, 10:09

Re: QueryBuilder и AR в отдельном пакете?

Сообщение skynin » 2019.08.09, 18:41

ElisDN писал(а):
2019.08.09, 17:58
Но вот зачем для юнит-тестов горы фикстур юзать? Или вы отдельные юнит-тесты не пишете?
Мой опыт еще с джавы что юнит-тесты почти ничего и не ловят.
Но да, есть корпоративные стандарты по покрытию, вот и пишут, пишут.
В основном джунов натаскивают на них :)

Но ок, пишем юнит-тест. По определению он тестит что-то микроскопическое.
И даже если этот функционал дергает с пяток таблиц, то нужно с этих таблиц что-то совсем чуть-чуть
Мокать что мешает?
И почему этот класс дергает сам, а не в него инжектятся данные?

Ну раз это система требующая обкладывания тестами, а не условный блог?

то есть - какая уже разница что там за прослойка работы с БД, если декомпозиция на классы уже пошла как в сложных системах?
ElisDN писал(а):
2019.08.09, 17:58
Да хоть MySQL. Всё равно есть отличия в возможностях и типах и без ХП.
Еще раз
Потребовались возможности конкретной БД
Зачем для бложика такая привязка?

А если это не бложик, то см выше
это как так проведена декомпозиция что юнит тест без дергания базы - не написать?
skynin писал(а):
2019.08.09, 17:38
И, второй момент
выбирать архитектуру потому что для нее тесты будут быстро выполняться, ну... это как-то странно.
ElisDN писал(а):
2019.08.09, 17:58
Выбирать для того, чтоб голова от мешанины не взорвалась.
ну, от количества слоев абстракций голова взрывается не меньше чем от богоклассов :)
ElisDN писал(а):
2019.08.09, 17:58
skynin писал(а):
2019.08.09, 17:38
Есть много технических и административных способов улучшить жизнь с медленными тестами.
Например?
только если с хабра собрать статьи как мы ускоряли наши тесты, получится книжица страниц на 100

и мы можем 101ую написать :)

поэтому - например, уже выше было
юнит-тесты медленные потому что нуждаются в БД?
а как это вы так декомпозировали что для юнит-тестов вам нужна БД?

может не тесты нужно ускорять, код рефакторить?
при чем не ради тестов, а согласно правилу

Если код сложно обложить тестами, то он наверное попахивает нехорошо.

А если это бложик, CRMка, то что там обкладывать - юнит тестами?
Когда там главная логика то - как раз работа с базой данных
Неврубающийся не может опознать врубающегося.

Аватара пользователя
ElisDN
Сообщения: 5468
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение ElisDN » 2019.08.09, 19:45

skynin писал(а):
2019.08.09, 18:41
Мой опыт еще с джавы что юнит-тесты почти ничего и не ловят.
Если, как вы говорите, это бложик на геттерах и сеттерах, то и ловить там нечего.
skynin писал(а):
2019.08.09, 18:41
Но ок, пишем юнит-тест. По определению он тестит что-то микроскопическое.
И даже если этот функционал дергает с пяток таблиц, то нужно с этих таблиц что-то совсем чуть-чуть
Мокать что мешает?
И почему этот класс дергает сам, а не в него инжектятся данные?
Ну вот есть у вас ActiveRecord с бизнес-логикой:

Код: Выделить всё

class User extends ActiveRecord
{
    public static function signUp(string $username, string $hash): self
    {
        $user = new self([
            'username' => $username,
            'password_hash' => $hash,
        ]);
        $user->save(false);
        $this->trigger(self::SIGNED_UP);
        return $user;
    }

    public function changePassword(string $hash): void
    {
        $this->update([
            'password_hash' => $this->password_hash = $hash;
        ]);
        $this->trigger(self::PASSWORD_CHANGED);
    }

    public function addPhone(string $number): void
    {
        if ($this->getPhones()->andWhere([['number' => $number])->exists()) {
            throw new DomainException('Phone already exists.');
        }
        $phone = Phone::create($number);
        $this->link('phones', phone);
        $this->trigger(self::PHONE_ADDED, new Event(['data' => ['phone' => $phone]]);
    }

    public function removePhone(int $id): void
    {
        $phone = $this->getPhones()->andWhere([['id' => $id])->one();
        if ($phone === null) {
            throw new DomainException('Phone is not found.');
        }
        if ($this->getPhones()->count() < 2) {
            throw new DomainException('Unable to remove the last phone.');
        }
        $this->unlink('phones', $phone);
        $this->trigger(self::PHONE_REMOVED, new Event(['data' => ['phone' => $phone]]);
    }
}
Что вы здесь будете мокать в каком-нибудь RemovePhoneTest? Три пачки фикстур для трёх тестовых методов напишете?
skynin писал(а):
2019.08.09, 18:41
Ну раз это система требующая обкладывания тестами, а не условный блог?
то есть - какая уже разница что там за прослойка работы с БД, если декомпозиция на классы уже пошла как в сложных системах?
Потребовались возможности конкретной БД
Зачем для бложика такая привязка?
А если это не бложик, то см выше
Бложики пишите на чём угодно. Паттерны не для бложиков придуманы.
skynin писал(а):
2019.08.09, 18:41
это как так проведена декомпозиция что юнит тест без дергания базы - не написать?
юнит-тесты медленные потому что нуждаются в БД?
а как это вы так декомпозировали что для юнит-тестов вам нужна БД?
Да хоть как декомпозируйте. Если взяли ActiveRecord (хоть дергающую внутри хранимку, хоть нет), то юнит тест без дергания базы уже без геморроя не написать.
skynin писал(а):
2019.08.09, 18:41
только если с хабра собрать статьи как мы ускоряли наши тесты, получится книжица страниц на 100
и мы можем 101ую написать :)
Ну вот зачем мне 300 тестов с БД ждать 60с, если могу их без БД запускать за 1с?
skynin писал(а):
2019.08.09, 18:41
может не тесты нужно ускорять, код рефакторить?
Если код сложно обложить тестами, то он наверное попахивает нехорошо.
Как рефакторить приведённый выше код с ActiveRecord, чтобы он не использовал БД?
skynin писал(а):
2019.08.09, 18:41
А если это бложик, CRMка, то что там обкладывать - юнит тестами?
Когда там главная логика то - как раз работа с базой данных
Если у вас бложек без логики, то нашлёпывайте CRUD-ы хоть на AR, хоть накликайте инфоблоками в Bitrix.
Если публичный хайлоад, то для скорости заморачивайтесь процедурками и регистрами под ассемблер.
Если корпоративная система со сложной бизнес-логикой, то удобнее Code-First, DataMapper и тесты.

Да, AR удобен для CRUD, но создаёт мешанину и тормозит тесты. Да, DM позволяет отделить бизнес-логику от БД, но не даёт напрямую дёргать хранимки. Что нравится и/или подходит, то и используйте. Цель вашего спора-то в чём?

Аватара пользователя
samdark
Администратор
Сообщения: 9251
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение samdark » 2019.08.09, 20:20

Ну, кстати, согласно пирамиде тестирования, покрыть функциональными и интеграционными тестами гораздо эффективнее, чем юнитом в плане отлова факта ошибки. Юнит, в основном, помогает найти причину, но не саму ошибку.

skynin
Сообщения: 207
Зарегистрирован: 2017.12.12, 10:09

Re: QueryBuilder и AR в отдельном пакете?

Сообщение skynin » 2019.08.09, 20:22

-- Что вы здесь будете мокать?
А что вы собрались здесь тестировать?
->count() < 2
?
->exists()
?
->one();
if ($phone === null

ну и как вы протестируете, есть в базе такая запись или нет - без базы?

на голых классах?

а что там тестировать, у голых классов то :)

-- Ну вот зачем мне 300 тестов с БД ждать 60с
а зачем вам 300 тестов которые почти ничего не тестируют :)

-- Как рефакторить приведённый выше код с ActiveRecord, чтобы он не использовал БД?
ну, если вам хочется писать тесты которые тестируют синтаксис языка программирования, то вынесете все в DTO классы, и тестируйте DTO классы :)
А потом гидратором забросьте в базу. с помощью пустых ActiveRecord, в конечном коде :)

-- Если корпоративная система со сложной бизнес-логикой, то удобнее Code-First, DataMapper и тесты.
у нас расчетная система, уровня начисления зарплаты.
как мы обкладываем то тестами расчетную часть без DataMapper...

то что вы привели - точно в DataMapper не нуждается.
почти пустые DTOшки будут.

Ваш пример как раз - прямая рекомендация для легковесной прослойки работы с БД

-- Цель вашего спора-то в чём?
Yii жалко. Хорош он именно благодаря ActiveRocrod

на кой для тьмы малых и средних проектов DataMapper?
Какие там еще 300 тестов, когда пара десятков интеграционных покроют всю ту смешную бизнес-логику что вы привели?
А малые проекты вообще ручным тестированием обходятся.

а энтерпрайза хочется, так берите Symfony. или вообще Джаву или Дотнет

-- но создаёт мешанину и тормозит тесты
не пишите тесты ради тестов.
или тесты тестирующие фреймворк.
и будет вам счастье :)

И второе
Знаете зачем DataMapper как паттерн появился?
Потому что приложения на Джаве и Дотнете висят в памяти.
У них другой цикл работы, чем у php
Там есть потребность как-то прозрачно синхронизировать объекты в памяти с персистентым хранилищем.
Муторно и ненадежно вручную - читать данные из БД и записывать, отслеживать изменения в памяти, отслеживать изменения в бд и т.п,

А не потому что это какая-то там академически правильная архитектура или скорость выполнения тестов лучше.

Пока же PHP - однопоточный и "рождается чтобы умирать" - DataMapper для проектов на нем - подслеповатое копирование решений из систем где есть проблема, в системы где такой проблемы вообще нет.

А вот если запущен PHP под каким-нить swoole, я первый скажу, о, надо DataMapper брать.

И, из той книжицы, что с хабра собрана, видно, что обычно число интеграционных тестов ощутимо превышает число юнит тестов.

Потому что юнит тесты мало что тестируют.
А нужны для того чтобы можно было рефакторить код в огромных командах, в проектах которые точно проживут больше 5 лет.

Юнит тесты же в php исходя из этого - чаще карго культ, чем практическая необходимость.
Неврубающийся не может опознать врубающегося.

Аватара пользователя
ElisDN
Сообщения: 5468
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение ElisDN » 2019.08.10, 00:17

skynin писал(а):
2019.08.09, 20:22
А что вы собрались здесь тестировать?
->count() < 2 ?
->exists() ?
->one(); if ($phone === null
Именно ту бизнес-логику, которая этими count и exists реализована. Видимо у вас своё понимание логики.
skynin писал(а):
2019.08.09, 20:22
ну и как вы протестируете, есть в базе такая запись или нет - без базы?
на голых классах?
а что там тестировать, у голых классов то :)
У таска есть хитрый метод changeStatus, который не просто меняет статус, а попутно переключает прогресс и устанавливает или сбрасывает даты начала и завершения. И к нему параллельно написаны семь юнит-тестов, которые все эти случаи проверяют. Работают на голом PHP без всякой базы за миллисекунду.

Логика проверена. И не надо все семь пачек фикстур сочинять. Лишь одну пачку для одного-двух интеграционных тестов на успех и валидацию.
skynin писал(а):
2019.08.09, 20:22
а зачем вам 300 тестов которые почти ничего не тестируют :)
Пишу, например, метод запроса восстановления пароля. И продумываю варианты:

- А что если предыдущий токен истёк? Надо сгенерировать и отправить новый.
- А что если уже запрошен и не истёк? Надо ругнуться и новый не посылать.
- А что если пользователь запрашивает сброс, ещё не подтвердив почту? Не надо посылать.
- А что если админ запросил восстановление у юзера из соцсети без емэйла? Надо ругнуться.

И по этим мыслям сразу пишу копипастой пачку из пяти тестов. И теперь уже пишу сам метод, на ходу вписывая нужные ему поля. В итоге сущность и юнит-тесты к ней написаны. Теперь можно спокойно делать таблицу в БД. Потом добавить контроллеры и API-тесты.

По 3 теста на 20 сущностей по 5 методов – вот и 300 тестов набралось.

В итоге 300 таких юнит-тестов выполняются за секунду, так что никому не мешают. Захочется отрефакторить приватный метод или элементарно поле переименовать - не вопрос. Поставил < вместо <= или забыл ! в if-е - сразу какой-нибудь тест упал. Удобно.
skynin писал(а):
2019.08.09, 20:22
ну, если вам хочется писать тесты которые тестируют синтаксис языка программирования, то вынесете все в DTO классы, и тестируйте DTO классы :)
DTO к логике никакого отношения не имеют. Я тестирую поведение, а не поля.
skynin писал(а):
2019.08.09, 20:22
на кой для тьмы малых и средних проектов DataMapper?
Какие там еще 300 тестов, когда пара десятков интеграционных покроют всю ту смешную бизнес-логику что вы привели?
А малые проекты вообще ручным тестированием обходятся.
Для малых и средних - ни на кой.
Последний раз редактировалось ElisDN 2019.08.10, 09:58, всего редактировалось 2 раза.

anton_z
Сообщения: 457
Зарегистрирован: 2017.01.15, 15:01

Re: QueryBuilder и AR в отдельном пакете?

Сообщение anton_z » 2019.08.10, 00:59

ElisDN писал(а):
2019.08.09, 17:58
skynin писал(а):
2019.08.09, 17:38
Есть много технических и административных способов улучшить жизнь с медленными тестами.
Например?
Поставить SSD или юзать tmpfs под базу. Реально, попробуйте, разница по скорости выполнения между "с базой" и "без базы" станет совсем небольшой.
ElisDN писал(а):
2019.08.09, 19:45
Да, DM позволяет отделить бизнес-логику от БД, но не даёт напрямую дёргать хранимки.
Не только, еще не дает перечитывать данные, работать с транзакциями, блокировать, вызывать функции БД.
ElisDN писал(а):
2019.08.09, 17:58

Да, для интеграционных тестов все используют и заполняют фикстуры. Это понятно. Но вот зачем для юнит-тестов горы фикстур юзать? Или вы отдельные юнит-тесты не пишете?
А я считаю, что классы взаимодействующие с базой нельзя да и неудобно тестировать без базы. База это часть приложения. Я писал много тестов, пробовал мокать подключение, но пришел к тому, что все это неверно, так как такие тесты получаются хрупкими и сложными. Не согласен, что код тестов AR с базой ну хоть в чем-то сложнее тестов сущностей в DataMapper. Наоборот, тесты с базой менее подвержены такой вещи как "ложноположительные результаты".
ElisDN писал(а):
2019.08.09, 19:45

Если корпоративная система со сложной бизнес-логикой, то удобнее Code-First, DataMapper и тесты.

Удобнее лично вам. Мне нет. У нас разные взгляды на это.

ElisDN писал(а):
2019.08.10, 00:17

У таска есть хитрый метод changeStatus, который не просто меняет статус, а попутно переключает прогресс и устанавливает или сбрасывает даты начала и завершения. И к нему параллельно написаны семь юнит-тестов, которые все эти случаи проверяют. Работают на голом PHP без всякой базы за миллисекунду.
Конечно, это учебное демо-приложение, поэтому к нему требования снижены, но все же, раз пошла такая тема: метод действительно "хитрый". В нем есть проверки текущего статуса, который может измениться в базе в другом процессе в момент после считывания сущности и до записи изменений в БД. С AR я могу такую блокировку прямо в этом методе сделать (хоть пессимистическую, хоть оптимистическую), связанный код будет в одном месте. А у вас по-моему блокировки нет. Пессимистической точно, оптимистическую не нашел.
В целом, после просмотра кода, у меня впечатление такое, что в целом несложное приложение написано очень сложным способом. Задействовав все практики DDD, привнесено сложности больше, чем убрано. Оверинжиниринг. А основная цель ООП - борьба со сложностью. Но это только мое мнение. Если вам так проще работается. почему бы и нет.

Ответить