«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
MVC без шаблонизатора Аноним 2019/02/26 14:26:42  №1355798 1
Верно ли утверждение, что без шаблонизатора мы не можем создать полноценную MVC на пхп, ведь шаблонизатор не убирает скрипты пхп из HTML, а заменяет его код на свой синтаксис, т.е. все скрипты их штмл никуда не деваются. Главная задача MVC отделить логику от представления, разве обязательно юзать шаблонизатор?
Ответы: >>1357547 >>1359947
Аноним 2019/03/02 01:09:23  №1357547 2
>>1357536
Я не понимаю, мои посты скрываются каким-то специальным скриптом? На них никто не знает ответ? Вопросы дурацкие? Или просто лень отвечать?

>>1355207
>>1355140
>>1354531
>>1355798

И в предыдущем треде дохуя.
Ответы: >>1357562 >>1359946
Аноним 2019/03/02 02:36:51  №1357562 3
>>1357547
Да просто не знают ответа ибо только учатся или посрать пришли
Аноним 2019/03/06 02:32:18  №1359946 4
>>1357547

У меня просто времени иногда нет, последние пару недель адски загружен. Как станет полегче - разберу накопившиеся вопросы. А так, я всем стараюсь отвечать.

>>1355207

> Нужно ли делать ячейку DI-контейнера одиночкой, если она нуждается в этом?

Ни в коем случае. Идея DI контейнера - IoC - предполагает, что жизнью объекта (когда его создать, когда уничтожить, что передать в зависимости) управляют снаружи, что это не его зона ответственности. Это не дело объекта-сервиса знать, сколько экземпляров сейчас создано. Дело сервиса - указать свои зависимости, например, в конструкторе или в методах.

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

Простой пример, когда нам не нужен синглтон - это тесты. Мы хотим, чтобы тесты выполнялись в изоляции друг от друга, и можем для каждого теста создавать одноразовый экземпляр DI контейнера. DI это позволяет, а твой подход с синглтонами - нет.

Потому синглтон - это почти всегда антипаттерн. Не стоит его использовать.

>>1355140

Я думаю, сервис провайдеры и сервисы хранятся в отдельных папках. По поводу организации структуры кода, если ты используешь фреймворк, то стоит делать, как там принято. Если не используешь, то такие варианты:

- если классов мало (< 10), их можно класть в одну папку
- можно делать папки по типам классов: папка для сервисов, для контроллеров, для представлений, для моделек, для классов работы с БД, для вспомогательных утилит. Этот подход начинает фейлиться, когда у тебя становится огромное приложение с сотнями серисов и моделей.
- можно взять предыдущий подход и добавлять подпапки внутри папок. Ну например, папка модели, а в ней: папка пользователи, папка товары, папка статистика итд.
- а можно поступить по-другому, и разбить приложение на "части". Для каждой "части" создаем свою папку, а в ней подпапки: сервисы, модели, контроллеры, утилиты и тд. То есть будет папка "пользователи", а в ней подпапки с моделями пользователей, контроллерами раздела работы с пользователями итд.

Симфони, например, использует что-то отдаленно напоминающее последний подход, где можно делать разные "части" - бандлы. У каждого бандла могут быть свои конфиги. Вообще, последний подход, если делать бандлы небольшими, хорошо работает в огромных приложениях. Так как часто у нас разработка идет в стиле "создаем новый раздел сайта, дорабатываем и потом почти не трогаем". И мы сидим в основном внутри одного небольшого бандла и не трогаем остальной код.

То есть для огромного магазина, например, можно сделать так:

CommonBundle - общий код, который используется всеми бандлами (не контроллеры или модели, а например, сервисы, утилиты, расширения фреймворка итд)
UsersBundle - управление пользователями, регистрация, личный кабинет
StoreBundle - витрина, вывод товаров, оформление заказа
FinanceBundle - оплата, бонусы
SupportBundle - раздел техподдержки
ForumBundle - форум
AnalyticBundle - аналитика
AdminBundle - админка
Ответы: >>1360508
Аноним 2019/03/06 02:32:48  №1359947 5
>>1355798

> что без шаблонизатора мы не можем создать полноценную MVC на пхп

В теории - можем. Например, если мы делаем сервер API, который отдает не HTML-страницы, а данные в формате JSON, то шаблоны нам не нужны. Ну и в теории, опять же, мы можем без шаблонов сделать вывод HTML кода кучей операторов echo.

То есть, шаблон - это лишь один из вариантов реализации View.

Я думаю, ты хотел спросить, "можно ли вместо стороннего шаблонизатора использовать встроенный в PHP?" - да, можно, но неудобно на больших проектах.

Урок про шаблонизаторы: https://github.com/codedokode/pasta/blob/master/php/templates.md

>>1354575

Обычно все сервисы создают через контейнер. Сегодня у сервиса нет зависимостей, а завтра они появятся - и тебе придется обходить весь код и заменять создание сервиса на получение через контейнер.

Также, контейнер может поддерживать существование одного экземпляра сервиса.

> если у меня просто вспомогательный класс (сервисного слоя) без зависимостей для контроллера я его просто делаю use и использую.

Для вспомогательных классов можно использовать паттерн Utility Class (класс со статичесикими методами).

> контракты в /app/Contracts а реализации их неизвестено где

Их реализации там, где уместно. Естественно, не в папке Contracts. Вообще, ты можешь посмотреть, как код организован в самом Laravel или стандартных библиотеках к нему.

Если у тебя мало сервисов, можно просто сделать папку App/Services. Если много - то думать, как дробить на части. Можно как-то по смыслу их группировать, по разделу сайта, по компоненту приложения.

>>1354604

По идее так: http://php.net/manual/ru/language.basic-syntax.phpmode.php

Но это даст низкокачественный код, потому читай https://github.com/codedokode/pasta/blob/master/php/templates.md
Аноним 2019/03/07 00:13:51  №1360508 6
>>1359945
>Реестр - это паттерн, который описыв
Спасибо, исчерпывающий ответ. Написал бы ты всеобъемлющую книгу по всем этим аспектам. Они ведь не устаревают. Будет пользоваться популярностью.

>>1359946
>У меня просто времени иногда нет, последние пару недель адски загружен.

А можно узнать, чем ты занимаешься? В студии трудишься или в каком-нибудь банке софт ваяешь?

>Ни в коем случае. Идея DI контейнера - IoC - предполагает
Хорошо, проблему синглтона контейнер решает.
А вот еще вопрос. Создал я класс подключения к мускулу, сделал для него сервис-провайдер, где он создается, а потом внедряю его, куда нужно.

А вот, скажем, мне нужен не один объект, а нужно итеративно и с условиями получить много, тогда что? Нужно будет в контейнере хранить не объект, а класс, а потом внедрять этот класс и там создавать через new?

>Я думаю, сервис провайдеры и сервисы хранятся в отдельных папках.

Спасибо, теперь все понятно.

>>1359948
Если у тебя используется дата маппер, то в нем и будет метод для загрузки моделек из БД.

То есть вообще всем управляет маппер, а сущности это такие пассивные ячейки памяти, к которым маппер обращается, и сущность сама по себе ничего делать не должна? И в контроллере правильно будет вызывать именно методы маппера?

>>1359949
> В задаче про студентов сортировку логично сделать аргументом в методе для получения студентов:

Спасибо за разъяснение особенно за последний абзац и за метод, ты сэкономил мне кучу времени.

>То есть перед выполнением нужных действий проверяем наличие логина. При отсутствии - редирект на форму логина с передачей текущего URL

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

>В твоем варианте пользователь может попробовать обойти авторизацию, вызвав напрямую метод "методПослеПосещения".

Но у него не получится, если я объявлю этот метод закрытым. Можно вообще все методы сделать закрытыми и вызывать их через indexAction, в котором сформировать настройки и всякие проверки. Сигнатуру формировать по маршруту. Получится эдакий фронт контроллер, только не физический файл, а метод. Но это что-то идиотское, да? Лол.

>Не думал, что у файлообменника такая сила. Сейчас, вроде начинающие разработчики делают сокращатели ссылок, но это уже неприлично просто.

А это разве не проще, чем файлообменник? Там ведь просто идет редирект на реальный URI при обращении к твоей ссылке. За вечер-другой можно сделать.

>>1359951
>Обычно делают отдельно шаблон для "лейаута" (шапка/подвал) и "контента". Лейаутов может быть несколько - например, один для морды, другой для админки. Как передавать параметры для лейаута? Тут есть варианты:


Я придумал вот что. Я в контроллере общем создал контейнер обычный массив data, куда записываю данные со всех уголков контроллеров и приходящие данные из моделей. В контроллерах-родителях задаю общие данные, в контроллерах специфичные, в методах контроллеров данные еще специфичнее. Данные записываются не через переопределение свойств, а через методы суперкласса.
Потом этот контейнер передаю в вид и обращаюсь к нему из шаблонов типа $data['title'], foreach($data['posts'] as $key => $post) {}, ну и все в таком духе. То есть "лейаут" и "контент" получаются данные из одного глобального массива data, переданного в вид. Так нормально?

>Не очень понятно, как это. Вызывать из одного шаблона другие шаблоны можно.

Ну я имел ввиду, можно ли несколько "контентов" подключать в "лейаут".

Спасибо за ответы, ты будто чистое знание вливаешь мне прямо в мозг. Я, бывает, что-то очень долго ищу, бывает, несколько дней занимает поиск ответа на какой-то вопрос, иногда бывает сам додумываюсь до ответа, но проблема в том, что я не знаю, правильный он или нет. Но вот так очень круто зайти сюда и прочитать ответы на все, что я задавал. Пасиба.
Ответы: >>1360509 >>1361818
Аноним 2019/03/07 00:15:56  №1360509 7
>>1360508
>а нужно итеративно и с условиями получить много, тогда что? Нужно будет в контейнере хранить не объект, а класс, а потом внедрять этот класс и там создавать через new?
Хранить в контейнере factory, через нее создавать объекты.
Ответы: >>1360515
Аноним 2019/03/07 00:35:41  №1360515 8
>>1360509
Еще до фабрик не дошел, сейчас самое время, спасибо, анонче.
Аноним 2019/03/10 06:19:53  №1361818 9
>>1360508

> А можно узнать, чем ты занимаешься?

Просто обычная удаленная работа.

> А вот, скажем, мне нужен не один объект, а нужно итеративно и с условиями получить много, тогда что? Нужно будет в контейнере хранить не объект, а класс, а потом внедрять этот класс и там создавать через new?

Можно хранить фабрику (класс, создающий нужные объекты), можно в контейнере сделать метод, который позволяет создавать объекты с параметрами. Но вообще, надо подумать, а нужны ли в таких объектах зависимости? Обычно, если это объект типа "Пользователь", у них нет зависимостей и их можно просто создавать через new. То есть такие "сущности" обычно в контейнер не кладут.

> То есть вообще всем управляет маппер, а сущности это такие пассивные ячейки памяти, к которым маппер обращается, и сущность сама по себе ничего делать не должна? И в контроллере правильно будет вызывать именно методы маппера?

Если ты читал мой урок https://github.com/codedokode/pasta/blob/master/db/patterns-oop.md то знаешь, что есть ACtiveRecord, где сущности умеют сами себя сохранять в БД и Data Mapper, где они не умеют.

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

> А можно такую проверку делать в конструкторах?

Плохая идея, из конструктора нельзя возвращать значения, да и он не для этого. Но ты можешь сделать метод вроде beforeRequest() и обязательно его вызывать из фронт-контроллера.

> Я придумал вот что. Я в контроллере общем создал контейнер обычный массив data, куда записываю данные со всех уголков контроллеров и приходящие данные из моделей. В контроллерах-родителях задаю общие данные, в контроллерах специфичные, в методах контроллеров данные еще специфичнее. Данные записываются не через переопределение свойств, а через методы суперкласса.

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