Bymas | Как правильно?

А если хочется больше ответов в таких направлениях советую посетить software architecture конференцию

Scammer (2 сен 2023, в 13:13)
На самом деле нагрузки не значительно больше если нет моментов где выборка идёт сотен записей и в обернутом виде, читаемость от этого стает лучше и масштабирование возможно, а когда оно размазано по всему проекту то достаточно сложно вносить изменения в будущем.
Например если вдруг какой-то из модулей свитчается к примеру на clickhouse (Так как работает с большими данными и надо менять технологию запросов, допустим модуль typeahead)
Так вот когда есть репозитории и сервисы и правильно используются DTO то это сделать достаточно легко изменив лишь репозиторий откуда подгружать данные даже больше можно делать a/b тестирование такой фичи, а когда оно все работает в mvp стайл то придётся кучу всего переписывать и костылить для внедрение нового

Если в будущем менять базу на postgres, то ничего переписывать и так не придется, да и зачем мне этот postgres - непонятно, у меня вся логика в php, я не собираюсь тянуть ее в sql. А если менять мускл на редис, то всеравно придется переписывать все эти where()->limit()->orderBy(), так что нет смысла короче.
Да и нет смысла съезжать с мускла, т.к. производительность у него норм, получше даже чем на postgre, плюс только mysql на всех хостингах есть. Так что не нужен ORM нам, простым честным ракам. Да и в ентерпрайзе ORM не нужен, точнее нужен, но только для того чтобы генерить индусский код, тоесть увеличивать свою зарплату путем увеличения количества строк кода. Ну ты понел)
________
посл. ред. 02.09.2023 в 13:32; всего 3 раз(а); by Something

Scammer (2 сен 2023, в 13:17)
А если хочется больше ответов в таких направлениях советую посетить software architecture конференцию

Лучше бы не за архитектуру трепались, а о расширении функционала и повышении производительности. Тем более что для каждого приложения архитектура будет своя, а если городить универсальную, то будет тормозное говно)
upd.
Плюс есть еще такое понятие как преждевременная оптимизация). Нет, я конечно не против преждевременной оптимизации, но только если она не в ущерб производительности :D
________
посл. ред. 02.09.2023 в 13:38; всего 1 раз(а); by Something

Something (2 сен 2023, в 13:34)
Лучше бы не за архитектуру трепались, а о расширении функционала и повышении производительности. Тем более что для каждого приложения архитектура будет своя, а если городить универсальную, то будет тормозное говно)
upd.
Плюс есть еще такое понятие как преждевременная оптимизация). Нет, я конечно не против преждевременной оптимизации, но только если она не в ущерб производительности :D

Архитектура для каждого своя это правда но есть паттерны которые годами делали и придумывали и полно бест практик)
Архитектура сильно связана с производительностью и расширениям функционала. Принимать это или нет твоё дело) но скажу на опыте что видел много разных подходов и той где достаточно хорошо все продумано и соответствует допустим clean architecture или DDD работа идёт более стабильно и нет факапов сильных
________
посл. ред. 02.09.2023 в 13:41; всего 1 раз(а); by Scammer

Scammer (2 сен 2023, в 13:40)
Архитектура для каждого своя это правда но есть паттерны которые годами делали и придумывали и полно бест практик)
Архитектура сильно связана с производительностью и расширениям функционала. Принимать это или нет твоё дело) но скажу на опыте что видел много разных подходов и той где достаточно хорошо все продумано и соответствует допустим clean architecture или DDD работа идёт более стабильно и нет факапов сильных

Вот эти паттерны и бест-практис - это и есть максимально сложная архитектура, типа под все случаи жизни, лол, которую пихают куда не надо с целью сгенерить побольше кода)). На выходе получается примитивнейшее, малофункциональное, но крайне тормозное говно). Причем еще и дорогое). Я конечно понимаю что надо разводить бизнес на деньги, но не ценой собственных страданий же.) Тот же MVC например зародился в Windows вроде еще в 70-х, и примерно тогда же устарел. А его до сих пор пихают в говносайты. Ну не абсурд?)
________
посл. ред. 02.09.2023 в 13:48; всего 2 раз(а); by Something

Something (2 сен 2023, в 13:34)
Лучше бы не за архитектуру трепались, а о расширении функционала и повышении производительности. Тем более что для каждого приложения архитектура будет своя, а если городить универсальную, то будет тормозное говно)
upd.
Плюс есть еще такое понятие как преждевременная оптимизация). Нет, я конечно не против преждевременной оптимизации, но только если она не в ущерб производительности :D

О преждевременной оптимизации никто не говорит, но когда задача постает узнать где тормиз система и проревьювить запросы в базу, то даже blackfire не поможет))
А зайти в репу и посмотреть или же по статистике узнать куда потерялись драгоценные секунды процессорного времени будет проще, проще внедрять или заменять модули, допиливать что-то.
Даже пример как будет выглядить две реализации (старая и новая) так чтоб провести a/b тестирование на ней в варианте где все размазано и там где следуют паттернам

Something (2 сен 2023, в 13:44)
Вот эти паттерны и бест-практис - это и есть максимально сложная архитектура, типа под все случаи жизни, лол, которую пихают куда не надо с целью сгенерить побольше кода)). На выходе получается примитивнейшее, малофункциональное, но крайне тормозное говно). Причем еще и дорогое). Я конечно понимаю что надо разводить бизнес на деньги, но не ценой собственных страданий же.) Тот же MVC например зародился в Windows вроде еще в 70-х, и примерно тогда же устарел. А его до сих пор пихают в говносайты. Ну не абсурд?)

MVC по сей день подходит для малых проектов.
Но с таким утверждением можно писать линейный код как это было 200х годах =)

Scammer (2 сен 2023, в 13:48)
MVC по сей день подходит для малых проектов.
Но с таким утверждением можно писать линейный код как это было 200х годах =)

MVC ни для каких не подходит, ни для малых, ни для больших. По крайней мере для проектов на php. За другие ЯП не скажу. но думаю что там аналогично.

Scammer (2 сен 2023, в 13:47)
О преждевременной оптимизации никто не говорит, но когда задача постает узнать где тормиз система и проревьювить запросы в базу, то даже blackfire не поможет))
А зайти в репу и посмотреть или же по статистике узнать куда потерялись драгоценные секунды процессорного времени будет проще, проще внедрять или заменять модули, допиливать что-то.
Даже пример как будет выглядить две реализации (старая и новая) так чтоб провести a/b тестирование на ней в варианте где все размазано и там где следуют паттернам

Если надо узнать где тормоз, то просто ставишь в разных местах microtime() и вычитаешь разницу. Ты эти басни будешь своему начальству рассказывать, мне-то зачем?)

Something (2 сен 2023, в 12:35)
Не знаю как такое загуглить, поэтому пишу здесь. Допустим у меня название таблицы находится в переменной. Есть обертка для подготовленных запросов. Как правильно прописать?

php

# Так?

db::fetchAssoc("SELECT * FROM `$table`");

# Или

db::fetchAssoc("SELECT * FROM `?`", $table);

# Или даже так?

db::fetchAssoc("SELECT * FROM ?", $table);

# 4 вариант

db::fetchAssoc("SELECT * FROM $table");

Интерполяция переменной непосредственно в строку запроса (не рекомендуется из-за уязвимости к SQL-инъекциям):
$db::fetchAssoc("SELECT * FROM $table");

Второй вариант, с использованием знака вопроса вместо переменной и передачей переменной как параметра, является более безопасным способом, так как предотвращает SQL-инъекции. Рекомендуется использовать второй вариант для обеспечения безопасности вашей базы данных.

$db::fetchAssoc("SELECT * FROM ?", [$table]);