Что почитать об архитектуре приложений и фреймворков на php?

Question

[NeoCode]

Добрый день!
Интересует хорошая литература (книги, циклы статей) по архитектуре приложений и фреймворков на php. Желательно на русском для более быстрого изучения.
Проблема в том, что сам язык я знаю, но совершенно не имею представления о правильной архитектуре приложений на php. А в большинстве книг обычно рассматривается синтаксис языка и какие-то примитивные примеры просто для ознакомления с синтаксисом.
Прежде чем решать часто задаваемый здесь вопрос о выборе фреймворка или написании чего-то своего с нуля на чистом php, неплохо сначала ознакомиться с принципами организации фреймворков, с задачами которые они решают; с паттернами проектирования на php; с лучшими практиками написания кода; изучить разбор частых архитектурных ошибок, которые допускают как новички, так и профессионалы; идеально было бы вообще подробно расписанное сравнение внутреннего устройства нескольких фреймворков, с обсуждением плюсов и минусов той или иной реализации и т.д.
Есть такая информация?

Answer 1

[Сергей Протько]

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

Так же хочу заметить что "архитектура" это не что-то эдакое, а общее понимание команды разработчиков о том как функционирует приложение. Если этого общего понимания нет - у вас нет архитектуры. У многих разработчиков понимание пропадает уже через пару месяце стихийной разработки. Так что помимо архитектуры важно еще и процессы/методологии разработки подтянуть.

Так же стоит заметить, что все это приследует одну единственную цель - сделать процесс разработки эффективным в краткосрочной и долгосрочной перспективе. Если скажем у вас все приложение построено на процедурах и глобальных переменных поддержка такого кода скорее всего будет сильно дороже.

но совершенно не имею представления о правильной архитектуре приложений на php

"Правильно" не бывает, все зависит от задачи. "Правильная" архитектура является:

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

Вот и все. Далее уже есть принципы SOLID (читать Роберта Мартина), GRASP (Крэйг Ларман), GoF (лучше тут почитать head first design patterns или даже начать с Мэта Зандстры, у него помимо паттернов еще про процессы мельком рассказано).

Ну и смысла в этом всем нет если вы еще до конца не осознали что есть инкапсуляция и полиморфизм. Многие могут рассказать что значат эти термины, но на практике эти знания они не могут применить (чаще всего страдает инкапсуляция)

или написании чего-то своего с нуля на чистом php

Такое решение может принимать только разработчик у которого уже есть за плечами хотя бы пяток лет опыта работы с различными (не одним) фреймворком и языками. В противном случае вы только будете заниматься бесполезным велосипедостроительством.

идеально было бы вообще подробно расписанное сравнение внутреннего устройства нескольких фреймворков

Берете Symfony или Zend и вперед. Все остальные фреймворки "проще". То есть скрывают больше от разработчика. После них уже можно брать что угодно.

p.s. еще прочитайте тут: www.phptherightway.com

Comments

[NeoCode]

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

[Сергей Протько]

NeoCode: я где-то предлагал изучать исходники фреймворков? Это глупо. Нужно примерно знать как работают абстракции которые ты используешь а не все досконально - жизни не хватит.

А по книгам - я дал вам указание на авторов, берем и читаем.

[Сергей Протько]

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

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

[NeoCode]

Сергей Протько: Дело не в паттернах проектирования (которые я так или иначе знаю из достаточно большого опыта на С++). Дело конкретно в том, что нет такого материала, в котором проводилось бы введение во все фреймворки сразу с их сравнением и одновременным рассмотрением различных частей и модулей. Видимо, об этом не пишут книги... а жаль. Ну попробую по крупицам собрать из разных статей...

[Сергей Протько]

NeoCode: объясните мне, зачем вам сравнение "всех фреймворков"?) Если архитектура фреймворка влияет на приложение - это так себе фреймворк. Например возьмем Yii - у него топорная архитектура, половина принципов нарушена, высокая связанность.... зато прототипы на нем клепать одно удовольствие. Другое дело что после придется все переписать.

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

Так же и Laravel например, просто из коробки идет ORM с высокой связанностью с базой данных.

Короче изучать фреймворки - глупо. Если слова "высокое зацепление" вам что-то говорят то в принципе просто возьмите Symfony или Zend, как я уже говорил. Ну и php the right way почитайте. Знание паттернов вообще ничего не дает, нужно понимание того, какие проблемы оно решает и за счет чего.

[madmis]

Поддерживаю Сергей Протько. Он вам правильные вещи говорит. Вы правильно мыслить научитесь, а потом и фреймворк подберете себе по душе.
Ну и исходники популярных фреймворков (Yii2, Laravel, Symfony) я все же почитал бы на вашем месте. В книгах (даже если вы найдете ту которую ищете) в основном описаны очень уж абстрактные вещи. А в коде вы все это можете увидеть в "реальности". Все эти фреймворки написаны достаточно умными и опытными людьми. И хоть написанный ими код не является каким-то стандартом, он все же задает какие-то нормы и может быть использован как пример для подражания.

[NeoCode]

Сергей Протько: Вот для того чтобы ЗНАТЬ, у каких фреймворков архитектура "топорная" а у каких нет, и не переписывать проекты много раз, мне и нужно общее представление о построении фреймворков как таковых. Еще - у меня есть некоторый стиль мышления, и хочется выбрать фреймворк наиболее близкий мне по духу.
Например тот же ORM - а нужен ли он мне вообще? Может лучше написать вручную models, выполняющие конкретные задачи с БД, запросы к базе в реальности будут достаточно сложными.

[Сергей Протько]

NeoCode:

> у каких фреймворков архитектура "топорная" а у каких нет, и не переписывать проекты много раз, мне и нужно общее представление о построении фреймворков как таковых

Не правильная предпосылка. Выбирать нужно исходя из тех целей, для которых задумывался фреймворк. Например есть Zend, который писался с оглядкой на лучшие практики в индустрии, которые помогают делать большие проекты. Symfony который предоставляет возможность использовать как и эти практики, так и многое упростить. Laravel так же - все то же что и в Symfony но уровень надежности приложений намного ниже (и этого хватает для 95% проектов). Yii - упор на быструю разработку и в жертву принесено масштабирование. То есть если вы взяли Yii у вас уже не выйдет "отделить" ваш код от фреймворка.

И самое интересное, если вы будете понимать что такое "связанность" кода и чем гразит слишком высокая связанность от фреймворка - то вам достаточно будет 20-ти минутного просмотра документации к фреймворку что бы определить слабые места.

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

> Например тот же ORM - а нужен ли он мне вообще? Может лучше написать вручную models, выполняющие конкретные задачи с БД

опять же, вы путаете ORM и ActiveRecord/DataMapper/DAO. ORM - это связи между объектами (Object Relational Mapping) в то время как ActiveRecord/DataMapper/DAO - это просто разделение ответственности по хранению данных. Рекомендую в этом плане Фаулера почитать - Шаблоны проектирования энтерпрайз приложений.

А то что у ваш там "некоторый стиль мышления" - опишите его. Возможно вам просто надо CRUD-ы фигачить а тут как бы что угодно сойдет.

[NeoCode]

Сергей Протько: спасибо, поставил вам плюсик в карму на хабре (здесь не знаю где) :) Вот то что вы описали про фреймворки - Zend, Symfony, Yii, Laravel - это мне и нужно знать (только гораздо более подробно, но и то что вы упомянули уже очень полезно). Такие тонкости как например обязательное наследование от системных классов и т.д. - без этого я слабо представляю как можно выбрать фреймворк. Да, я еще путаюсь в терминологии, любая серьезная статья по вебу на хабре - и сразу россыпь аббревиатур и терминов, ссылающихся один на другой :)

[Сергей Протько]

NeoCode: короче вам нужна книга-книг по фреймворкам которая объективно их оценивает - таких нет. Это как искать объективную оценку 5-ти конкурирующих продуктов. Вы такой не найдете или она не ответит на все ваши вопросы.

К сожалению нужно пробежаться по документации фреймворков (обычно есть что-то типа getting started или big picture). Качество документации к слову тоже стоит учитывать.

[NeoCode]

Сергей Протько: мне бы хотя-бы книгу, где где автор бы провел читателя от простого php-файла с "hello world" до современного фреймворка уровня Symfony/Yii/Laravel. Чтобы провел по каждому компоненту и по каждому архитектурному решению, с объяснениями - начиная от "что это такое", и далее, зачем возникли потребности в том или ином компоненте фреймворка, какие задачи он решают, почему это сделано именно так. С иллюстрацией эволюции различных решений, с размышлениями на тему "как лучше и почему".
Ну то есть умное что-то, а не учебники php для чайников и не документация, которая по сути лишь описание API.

[Сергей Протько]

NeoCode: таких книг нет. Есть просто по архитектурным решениям но они даже не по PHP. Извините, но вы просто хотите "легкий" путь. Книга под вас.

Answer 2

[Jazzist]

1. Мартин Фаулер "Рефакторинг"
   
2. Боб Мартин "Чистый код"
   
3. Про паттерны проектирования в википедии, на форумах и на узких форумах
   
4. "Приемы объектно-ориентированного проектирования. Паттерны проектирования" Авторы: Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес
   

За месяц-два реально разобраться и применять. Если практикуете - то быстрее.

Comments

[NeoCode]

Это об архитектуре вообще. Возможно я неправильно сформулировал вопрос, но меня интересует не "архитектура вообще", а прикладные, практические нюансы организации современных фреймворков на php.

Answer 3

[xmoonlight]

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

Касательно веб-сайта: базовая архитектура и все этапы разработки: https://sitecoder.blogspot.ru/p/blog-page_23.html

Comments

[NeoCode]

Это очень общее. Меня интересует скорее множество деталей реализации и аргументация выбора тех или иных деталей. Вот например сейчас я взял конкретную тему (одну из сотен на самом деле) - "шаблонизаторы". И возникает множество вопросов как сделать лучше и почему в той или иной реализации сделано тем или иным способом. Почему придумывают свои специальные языки, а не пользуются php? Должен ли это быть единый html во вставками php, или группа php-функций, отдающих конкретные блоки страницы, и затем вызываемая в нужной последовательности, или еще как? Какое решение лучше для страниц с сильно динамическим контентом (социальная сеть например)? Ну и еще множество вопросов. И так по каждой теме...

[xmoonlight]

NeoCode: Полностью согласен, что у меня - общая схема.
Однако, могу ответить на все Ваши вопросы, т.к. я создавал свой фреймворк именно решая заданные Вами вопросы один за другим)))

Шаблонизатор - фактически, это модуль размещения компонентов внутри страницы на основе запрошенных и полученных системой (на основе вычислений) данных.
Аналогия: шаблонизатор - центр контроля "барж" (самые крупные области минимальной сетки шаблона), несущих на себе отдельные "контейнеры" (компонентные блоки).
Итак, прошли все вычисления (уровень приложения) и Вы получили в объектный массив коды размещения на странице - "контейнеры".

Задача шаблонизатора - "погрузить" эти контейнеры на области сетки шаблона в зависимости от различных текущих условий (обычно, только URL и ACL) и зависимости этих "контейнеров" между друг другом для корректной работы на стороне клиента (строится "дерево" зависимостей, где указывается что от чего зависит: без каких "контейнеров" нет смысла выводить, подобно службам в Windows).
Кэшируется шаблон обычно так: URL (сервис без параметров), текущие права ACL, готовая сетка размещения "контейнеров" без загрузки контента, внутри текста будет, например:
"::login[0]::" и где-то справа с тэгами
::similar_article[0]::
::similar_article[1]::
::similar_article[2]::
и т.д.
Затем в получившийся шаблон расставляется контент из этих "контейнеров" (массив подготовленных объектов из уровня приложения ) и получается готовая страница.
В очередной раз, если есть в кэше - мы переходим сразу от вычислений к расстановке данных из "контейнеров" уже по имеющейся готовой разметке, минуя все расчеты зависимостей при формировании нужного представления.