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

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

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

Сообщение anton_z »

ElisDN писал(а): 2019.07.24, 15:31
Либо урезанный Active Record, либо дополненный поведением Row Data Gateway. Но никак не урезанный Row Data Gateway.

Изначально не ради независимости от БД, а ради разделения логики от хранения/представления. Как мы HTML-код выносим в отдельные представления, чтобы не конкатенировать PHP+HTML лапшу прямо в контроллере, так и выносим SQL в отдельное место, чтобы не мешать PHP+SQL лапшу в сущности. Ну и для удобства тестирования чистого PHP-кода без БД. А независимость идёт бонусом.

P.S. Практически все претензии от нелюбителей ORM в десятках статей сводятся к неудобствам, которые всплывают при использовании ORM не по назначению. Когда её вместо мэппинга доменных сущностей пытаются использовать для листингов и отображений в UI.
DataMapper реально лишает нас многого. Например, как заблокировать строку в БД на изменение изнутри сущности Doctrine ORM? Никак. Только снаружи. - из сервиса. А с инкапсулированным подключением это делается легко изнутри объекта. Уровень инкапсуляции выше.

Eloquent мне нравится, отличная реализация ActiveRecord.

Аналогия с разделением логики представления и данных для меня неуместна. По мне так основная логика приложения это преобразование данных. БД это отличный специально разработанный инструмент по обработке данных, а не тупое хранилище. Отделять от нее бизнес логику считаю неверным.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

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

Сообщение samdark »

в Yii очень не хватает гибкого валидатора для валидации вложенных массивов/хешей
А можно создать новую тему и раскрыть это? Валидаторы я запилил уже более-менее, но вот этого там пока нет и я не особо понимаю чем это должно быть.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z »

samdark писал(а): 2019.07.24, 16:26
в Yii очень не хватает гибкого валидатора для валидации вложенных массивов/хешей
А можно создать новую тему и раскрыть это? Валидаторы я запилил уже более-менее, но вот этого там пока нет и я не особо понимаю чем это должно быть.
viewtopic.php?f=38&t=51463
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z »

Вот еще интересная статья в тему: https://habr.com/ru/post/459438/
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

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

Сообщение ElisDN »

anton_z писал(а): 2019.07.24, 15:56 Аналогия с разделением логики представления и данных для меня неуместна. По мне так основная логика приложения это преобразование данных. БД это отличный специально разработанный инструмент по обработке данных, а не тупое хранилище. Отделять от нее бизнес логику считаю неверным.
Мы уже говорили, что для вас в приложении главное – это обработка и хранение данных. В этом вам ORM мешает.

Для меня же главное в приложении – это бизнес-логика при автоматизации бизнес-процессов. В этом мне ORM помогает.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z »

ElisDN писал(а): 2019.07.24, 16:58
для вас в приложении главное – это обработка и хранение данных. В этом вам ORM мешает.
Неправда. Для меня бизнес-логика не менее важна. В ее реализации мне помогает СУБД, DataMapper ORM мешает. У вас бизнес-логика данные разве не обрабатывает/сохраняет?
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

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

Сообщение ElisDN »

anton_z писал(а): 2019.07.24, 17:07 Неправда. Для меня бизнес-логика не менее важна. В ее реализации мне помогает СУБД, DataMapper ORM мешает.
Пример кода приведёте как вы на СУБД логику программируете?
anton_z писал(а): 2019.07.24, 17:07 У вас бизнес-логика данные разве не обрабатывает/сохраняет?
У меня – не преобразовывает и не сохраняет. Мэппит и сохраняет уже ORM.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z »

ElisDN писал(а): 2019.07.24, 17:42
Пример кода приведёте как вы на СУБД логику программируете?
Вы не поняли. Логику я программирую в основном в приложении. Иногда использую хранимые процедуры, триггеры. Запросы делаются из ООП приложения, из объектов, между которыми распределены обязанности по генерации запросов и интерпретации результатов. То что я не ограничиваю своей бизнес-логике доступ к СУБД позволяет мне делать работу кода быстрее, проще, за счет того что доступен весь инструментарий СУБД. Например, если мне надо внутри AR начать новую транзакцию и заблокировать запись, перечитать запись, я могу это сделать, а с DataMapper внутри POPO это будет треш.

А вы не думали с помощью чего достигается "автоматизация бизнес-процессов"? За счет организации быстрого доступа к информации всех заинтересованных лиц .обработанной подготовленной информации. Эта информация в приложениях представлена в виде данных. СУБД типа MSSQL, Oracle, PostgresSQL, MySQL как раз и задумывались как инструменты по обработке данных для построения таких вот бизнес-систем. Бизнес-логика это как раз алгоритмы по преобразованию таких данных исходя из бизнес-правил. Используя DataMapper мы убираем весь мощный инструментарий СУБД на низкий уровень, и заменяем его в коде приложения на очень ограниченные POPO, которые ничего не могут потому что у них нет доступа к подключению к СУБД, и соответсвенно, ее функционалу. Я считаю это неверным, даже AR в этом плане куда лучше.
ElisDN писал(а): 2019.07.24, 17:42 У меня – не преобразовывает и не сохраняет.
И что же она по-вашему делает тогда? Крутится сама по себе?
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

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

Сообщение maleks »

И как теперь верить в "Все, что ни делается, — к лучшему" ? :)

Цель была изначально перестроить на компонентный фреймворк чтобы по минимуму части можно было установить, а в процессе "отвалился" такой важный центровой агрегат как AR (да и query builder).

Процесс миграции на такую версию фрейма вангую станет тем еще вызовом.

Множество толковых готовых расширений все они тем или иным образом работают с БД через AR.
Будут ли они мигрированы?
А новые создаваться будут как? На усмотрение разработчика - cycle или eloquent.
Множество функционала ведь именно вокруг AR крутится.
Yii2 universal module sceleton - for basic and advanced templates
myks1992@mail.ru
Сообщения: 147
Зарегистрирован: 2017.11.15, 23:54

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

Сообщение myks1992@mail.ru »

maleks писал(а): 2019.07.26, 15:55 И как теперь верить в "Все, что ни делается, — к лучшему" ? :)

Цель была изначально перестроить на компонентный фреймворк чтобы по минимуму части можно было установить, а в процессе "отвалился" такой важный центровой агрегат как AR (да и query builder).

Процесс миграции на такую версию фрейма вангую станет тем еще вызовом.

Множество толковых готовых расширений все они тем или иным образом работают с БД через AR.
Будут ли они мигрированы?
А новые создаваться будут как? На усмотрение разработчика - cycle или eloquent.
Множество функционала ведь именно вокруг AR крутится.
Эта проблема возникла только потому, что фреймворком долгое время хорошо никто не занимался. Спустя года мир изменился, соотвественно "по старому" уже нет смыла переделывать фреймворк. Переделывать фреймворк постепенно тоже нет смысла и затратно. Поэтому приходится идти на такие решения. Это моё мнение. А расширения появятся со временем. Для этого команда Yii будет поддерживать ещё долго версию Yii2. За это время появятся новые пакеты и перепишутся старые. Вот поэтому и придется сломать большинство пакетов, потому что они не могут быть переиспользованы. Только в рамках Yii и то не все такие пакеты хорошо реализованы.
Аватара пользователя
Антон Смирнов
Сообщения: 284
Зарегистрирован: 2011.07.08, 10:37
Контактная информация:

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

Сообщение Антон Смирнов »

myks1992@mail.ru писал(а): 2019.07.28, 17:19 Эта проблема возникла только потому, что фреймворком долгое время хорошо никто не занимался. Спустя года мир изменился, соотвественно "по старому" уже нет смыла переделывать фреймворк. Переделывать фреймворк постепенно тоже нет смысла и затратно. Поэтому приходится идти на такие решения. Это моё мнение. А расширения появятся со временем. Для этого команда Yii будет поддерживать ещё долго версию Yii2. За это время появятся новые пакеты и перепишутся старые. Вот поэтому и придется сломать большинство пакетов, потому что они не могут быть переиспользованы. Только в рамках Yii и то не все такие пакеты хорошо реализованы.
Это не ваше мнение, это скопированное мнение от диванных аналитиков. Yii2 быстро работает, отлично расширяется и позволяет быстро писать сложные штуки, которые стабильно работают и могут несложно поддерживаться другими программистами.

Yii3 - это уход от практики, уход в сторону сложности, увеличения скорости, с "вынесением готовых плюшек фронтэнда из Yii" под прикрытием "сложно тестировать", "так не модно" и "др", а на деле - Yii2 ничего нового не приносит, а Yii3 - еще нет.
wolfy-j
Сообщения: 2
Зарегистрирован: 2019.07.29, 16:56

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

Сообщение wolfy-j »

anton_z писал(а): 2019.07.25, 02:21 Например, если мне надо внутри AR начать новую транзакцию и заблокировать запись, перечитать запись, я могу это сделать, а с DataMapper внутри POPO это будет треш.
Никто не запрещает работать с DataMapper в виде AR и так-же инкапсулировать соединение или транзакцию, объем кода будет не намного больше. Основной вопрос в том как тестировать такой AR код.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z »

wolfy-j писал(а): 2019.07.29, 17:03 Никто не запрещает работать с DataMapper в виде AR и так-же инкапсулировать соединение или транзакцию, объем кода будет не намного больше. Основной вопрос в том как тестировать такой AR код.
Это уже будет не DataMapper. А вы реально пробовали так делать? Вопрос зачем тогда нужен DataMapper если можно инкапсуляцию подключения пользовать на AR?

AR вместе с базой с фикстурами тестируется без проблем. В Yii2 и codeception для этого есть всё. Заодно протестите, что ограничения БД на типы данных и всякие constraints отрабатывают и не сломают приложение.

P.S. Я не знаю, откуда пошло само восприятие СУБД как какой-то "хранилки". По мне это ошибка, а СУБД - одна из центральных частей приложения, которое работает с данными (например, CRM, магазины, сайты знакомств. СМИ, сайты-агрегаторы и пр.). СУБД уже представляет собой достаточно высокоуровневую абстракцию над голыми данными (SQL это высокоуровневый декларативный язык для работы с данными). Это становится понятно, когда попытаешься реализовать работу с данными на простых файлах в качестве замены СУБД, когда наешься всех этим проблем с конкурентным доступом, вводом/выводом, необходимостью индексирования и прочим. Мое мнение, не надо мощь СУБД ограничивать и закапывать, как это делает DataMapper, а напротив надо дополнять, как делает AR, инкапсулируя подключение.
myks1992@mail.ru
Сообщения: 147
Зарегистрирован: 2017.11.15, 23:54

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

Сообщение myks1992@mail.ru »

anton_z писал(а): 2019.07.30, 06:41
wolfy-j писал(а): 2019.07.29, 17:03 Никто не запрещает работать с DataMapper в виде AR и так-же инкапсулировать соединение или транзакцию, объем кода будет не намного больше. Основной вопрос в том как тестировать такой AR код.
Это уже будет не DataMapper. А вы реально пробовали так делать? Вопрос зачем тогда нужен DataMapper если можно инкапсуляцию подключения пользовать на AR?

AR вместе с базой с фикстурами тестируется без проблем. В Yii2 и codeception для этого есть всё. Заодно протестите, что ограничения БД на типы данных и всякие constraints отрабатывают и не сломают приложение.

P.S. Я не знаю, откуда пошло само восприятие СУБД как какой-то "хранилки". По мне это ошибка, а СУБД - одна из центральных частей приложения, которое работает с данными (например, CRM, магазины, сайты знакомств. СМИ, сайты-агрегаторы и пр.). СУБД уже представляет собой достаточно высокоуровневую абстракцию над голыми данными (SQL это высокоуровневый декларативный язык для работы с данными). Это становится понятно, когда попытаешься реализовать работу с данными на простых файлах в качестве замены СУБД, когда наешься всех этим проблем с конкурентным доступом, вводом/выводом, необходимостью индексирования и прочим. Мое мнение, не надо мощь СУБД ограничивать и закапывать, как это делает DataMapper, а напротив надо дополнять, как делает AR, инкапсулируя подключение.
Как то вы очень негативно настроены против DataMapper. Тогда почему, интересно, его используют на крупных проектах и передовых фреймворках вроде Symfony?) AR, как паттер не плохой. Мне он тоже нравится для простых задач вроде CRUD. Если разработка сложнее чем CRUD — нарушается паттерн единой ответственности .

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

С этим жить можно, но переписывая каждый раз саму модель всякий раз когда одна из ответственностей терпит изменения. Например, нам нужно отобразить данные в другом виде. Нам приходится лезть в модель и добавлять/изменять метод доменной сущности. А если бы у нас было отдельная ViewModel, то данные бы мы изменили только там. К тому же мы бы не имели методы для отображения UI в DomainModel. Если из коробки будет хороший генератор кода, то время не сильно увеличится на старте. Зато в дальнейшем сильно уменьшиться.

Тестировать это можно, особенно если не использовали стандартный генерируемый код. Однако такие тесты выполняются на много дольше. С этими тестами много сложностей. Да и зачем нам тестировать поведение бд при модульном тестировании именно доменного слоя? А ещё базу создавать. И тут сразу же тестируем все. И валидация и сценарии и все что не нужно. В итоге код не то что бы применить на другом фреймворке нельзя, а поддерживать сложно как тесты, так и сам код.

Поэтому, DataMapper, наверное, имеет какие-то недостатки, но это лучше, чем зарыться в своём же коде. Зато он позволяет разделить всё по своим ответственностям на слоистую архитектуру. При этом позволяет работать с малым использованием функционала не создавая свои репозитории.

При таком подходе мы можем разделить слои более детально.

Domain Model != ViewModel
Domain Model != Repository
Domain Model != Validation
И так далее...

Кроме того вам не мешает никто использовать ваш совершенный SQL запрос вместо DataMapper) Но вы сами сказали как было проблемно реализовать работу с файлами. Вот так же вам будет проблемно перевести сущности из СУБД обратно в Файлы. Или вам потребуется сделать «плоскую базу» и тут вы уже тоже сломаете свой проект. Как вы будете тестировать в таком случае?)

Ещё раз повторю, что не пытаюсь вас обидеть)) Ждём YII3!))
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z »

myks1992@mail.ru писал(а): 2019.07.30, 11:34
Как то вы очень негативно настроены против DataMapper. Тогда почему, интересно, его используют на крупных проектах и передовых фреймворках вроде Symfony?)
Мир разработки очень подвержен хайпу.
myks1992@mail.ru писал(а): 2019.07.30, 11:34
Если разработка сложнее чем CRUD — нарушается паттерн единой ответственности .
Паттерн ActiveRecord сам по себе не нарушает SRP. Да и SRP не то чтобы очень хороший и понятный принцип. Мне больше нравится LowCoupling/HighCohesion.

https://sklivvz.com/posts/i-dont-love-t ... -principle
myks1992@mail.ru писал(а): 2019.07.30, 11:34 Или вам потребуется сделать «плоскую базу» и тут вы уже тоже сломаете свой проект. Как вы будете тестировать в таком случае?)
Извините, не понял, что вы имеете ввиду.
myks1992@mail.ru писал(а): 2019.07.30, 11:34
Domain Model != ViewModel
Domain Model != Repository
Domain Model != Validation
И так далее...
C AR тоже можно сделать слои. И я так и делаю. Логику взаимодействия с базой инкапсулирует AR, Query и Table классы. Все остальное обращается для взаимодействия с БД к ним. Подключение к БД внутри этих классов. SQL в клиентский код (контроллеры, сервисы) не протекает.

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

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

Сообщение BrusSENS »

О боги. Посмотрел Cycle и понял, что это отпрыск грязных игр Yii2 AR и доктрины.
Наблюдаю за тем что происходит с тройкой и понимаю, что многие останутся на второй ветке ещё долгое время. Потом будет участь CI и т.п. фреймворков. Отличнейший инструмент превращается в неповоротливого монстра. Той скорости уже не будет и рядом, я уверен почему-то в этом. Пугает это слишком.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

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

Сообщение ElisDN »

BrusSENS писал(а): 2019.08.07, 06:17 Наблюдаю за тем что происходит с тройкой и понимаю, что многие останутся на второй ветке ещё долгое время. Потом будет участь CI и т.п. фреймворков.
Это будет отличный антикейс революционного хаоса вместо эволюционного развития.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z »

ElisDN писал(а): 2019.08.07, 09:31
Это будет отличный антикейс революционного хаоса вместо эволюционного развития.
Вы провидец? А в чем заключается хаос? Почему вы считаете переход к DataMapper эволюционным развитием?
BrusSENS писал(а): 2019.08.07, 06:17 О боги. Посмотрел Cycle и понял, что это отпрыск грязных игр Yii2 AR и доктрины.
Наблюдаю за тем что происходит с тройкой и понимаю, что многие останутся на второй ветке ещё долгое время. Потом будет участь CI и т.п. фреймворков. Отличнейший инструмент превращается в неповоротливого монстра. Той скорости уже не будет и рядом, я уверен почему-то в этом. Пугает это слишком.
Мысли такие же есть. Хайп вокруг DDD и DataMapper. Ничего, наедятся, потом все вернется, может в других инструментах, не в Yii. Проходили уже.
Последний раз редактировалось anton_z 2019.08.07, 13:44, всего редактировалось 1 раз.
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

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

Сообщение ElisDN »

anton_z писал(а): 2019.08.07, 12:23 Вы провидец?
Местами да.
anton_z писал(а): 2019.08.07, 12:23 Почему вы считаете переход к DataMapper эволюционным развитием? И в чем заключается хаос?
Вам показалось. Наблюдаемый сейчас резкий переход к DataMapper или куда-то ещё - это и есть революционный хаос, который вам и мне не нравится.

Я как раз за спокойную эволюцию по пути выпуска микрорелизов с постепенным своевременным обсуждением, рефакторингом, разделением и внедрением. Например:
  • в 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".
skynin
Сообщения: 400
Зарегистрирован: 2017.12.12, 10:09

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

Сообщение skynin »

myks1992@mail.ru писал(а): 2019.07.30, 11:34 Тогда почему, интересно, его используют на крупных проектах и передовых фреймворках вроде Symfony?)
А на очень крупных Java, .NET, Go

Аргумент про "крупные" проекты плох тем, что проекты не всегда - крупные.
myks1992@mail.ru писал(а): 2019.07.30, 11:34 Если разработка сложнее чем CRUD — нарушается паттерн единой ответственности .
Сервисный слой над AR - дело рук самого программиста.
Не хотите нарушать - НЕ нарушайте.
myks1992@mail.ru писал(а): 2019.07.30, 11:34 Как всем известно что одна модель отвечает за сущность, за валидацию, за отображение данных, за сохранение в базу и умудряются ей ещё сохранять Файлы и осуществлять переводы. Поэтому он сложный в больших проектах.
Не он сложный, а указанный подход - не годится.
В большом проекте никто не запрещает использовать паттерн ActiveRecord как продвинутый TableGateway
myks1992@mail.ru писал(а): 2019.07.30, 11:34 Но на старте хорош.
Нередко проекты там и заканчиваются, на старте.
myks1992@mail.ru писал(а): 2019.07.30, 11:34 С этим жить можно, но переписывая каждый раз саму модель всякий раз когда одна из ответственностей терпит изменения.
Не переписывайте, а выделяйте бизнес ответственности в отдельные сущности.
myks1992@mail.ru писал(а): 2019.07.30, 11:34 Например, нам нужно отобразить данные в другом виде.
Наращивайте ActiveQuery или напишите свой датапровайдер
myks1992@mail.ru писал(а): 2019.07.30, 11:34 Нам приходится лезть в модель и добавлять/изменять метод доменной сущности.
А не надо приравнивать AR к доменной сущности. Это более легковестный, упрощенный паттерн.
myks1992@mail.ru писал(а): 2019.07.30, 11:34 А если бы у нас было отдельная ViewModel,
Сделайте ее
myks1992@mail.ru писал(а): 2019.07.30, 11:34 Поэтому, DataMapper, наверное, имеет какие-то недостатки, но это лучше, чем зарыться в своём же коде.
Каждая вещь имеет недостатки. Которые одновременно преимущества.
Зависит от ситуации и способа применения.
myks1992@mail.ru писал(а): 2019.07.30, 11:34 Зато он позволяет разделить всё по своим ответственностям на слоистую архитектуру.
Если вы не можете ее спроектировать в Yii, по ситуации, то запутаетесь и в Симфони.
myks1992@mail.ru писал(а): 2019.07.30, 11:34 При этом позволяет работать с малым использованием функционала не создавая свои репозитории.
А они не панацея и в крупных проектах.

Вообще, DDD - ну очень спорная штука. И точно никак не панацея.
myks1992@mail.ru писал(а): 2019.07.30, 11:34 Кроме того вам не мешает никто использовать ваш совершенный SQL запрос вместо DataMapper)
Так же как и не использовать DataMapper а использовать паттерн ActiveRecrod

Я выбирал Yii2 как раз из-за ActiveRecord

Если в Yii3 будет "Doctrine", тогда лучше сразу брать Symfony, или уходить на Laravel
Последний раз редактировалось skynin 2019.08.07, 13:50, всего редактировалось 2 раза.
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
Ответить