Архитектура web приложений php

Lets do PHP

PHP is the most beautiful web development language. You can do what ever you want using PHP. I have been loving it since I was in college and still I feel it is the best in terms of simplicity and yet capability. My intention here is to show how basic web functionalities can be implemented by PHP easily.

Architecture Diagram of PHP based web applications

A1: First user accessed the website through browser. That means user types the URL of the website in browser and hit go.

B1: The page request on browser will reach to the Web Server (Apache).

C: Web server will collect that requested page (HTML or PHP or Image file etc) from its document root. (In our example it will be www folder in WAMP. You will see it in next one)

B2: Now if it is a static element like HTML , CSS , image file or Java Script file then Apache will send it directly to browser.

A2: And Browser will render it to user on screen

D1 : If it is a PHP file then Apache sends the content of the file to PHP Interpreter. PHP interpreter interprets the PHP code and executes it. if DB operation is required it performs the same (E)

D2: PHP Interpreter generates output (if the PHP code is to generate any output) and sends to Apache

B2: Apache sends that content to browser

A2: Browser renders it to users’ screen

All static components like HTML, CSS files ,Image Files , Java Scripts etc doesn’t need interpreter. Our web browsers are built to render them and display on screen properly. That is why if user requests for these kind of components Apache collects them from Document root and sends back to Browser directly.

Only if requested page is a PHP page Apache will send it to PHP interpreter to get it translated and executed.

That is why though those listed static components reside on Server we will consider them as part of User Interface and as they get rendered at user’s browser we may refer them as Client side components. In web technology Browsers are Client terminals.

And for similar reason we will refer PHP files as Server side components as they have dependencies on another Server Side component PHP Interpreter and cannot be executed only on browsers.
Now let me explain the keywords of the definition as you will be able to understand them better

1. PHP files are kept on Server (in Document root) — Server Side
2. PHP Interpreter interprets PHP language and executes instructions as per code.It does not need compilation( This is way deep and different topic to discuss in a separate forum) — Scripting language

Источник

Пошаговый алгоритм создания архитектуры PHP-сайта

Дисклеймер: этот текст меня заставило написать практически полное отсутствие вменяемых материалов по данной теме на русском языке. Этому плохо учат в вузах, об этом молчат самоучители PHP и официальный мануал, хотя это самый важный момент при разработке программы — создание архитектуры. Плохая архитектура может убить ваш проект, так что он никогда не увидит свет. Хорошая архитектура даже при плохом коде, а кто из новичков пишет хороший код, способна творить чудеса.

Разработка архитектуры должна начинаться в тот момент, когда вам в голову пришла идея «хочу сайт такой-то» или кто-то вложил идею «нужен сайт такой-то». К сожалению, большинство разработчиков сразу приступают к написанию кода, причём даже не того, какого нужно.

Прежде чем писать код, вооружитесь листочком с ручкой, вордпадом, вордом, райтером или даже вашим редактором кода и выполните пару шагов.

Шаг 1. Постановка главной задачи

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

Многие программисты начинают разработку сайтов с роутеров, подключения к БД, обработки ошибок, что приводит к необходимости переписывания их кода в будущем или обильной вставке в код костылей, как только они натыкаются на то, что не смогли предусмотреть.

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

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

Итак, вам нужен блог, интернет-магазин, сайт стоматологической клиники.

Определитесь, что на вашем сайте самое главное, ради чего всё затевается.

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

Уже можем написать немного кода, с которого и начнётся разработка сайта:

или class товары <>, или class услуги<>

Это ваша главная подсистема. Сразу же можно написать, чем именно она будет управлять.

или class товар <>, или class услуга<>

Шаг 2. Определить, что ваша система умеет делать

Мы создали главную подсистему «записи». Следующий шаг: определить, что она будет уметь, чему мы хотим научить наш сайт.

Очевидно, она должна уметь создавать записи, удалять записи и получать записи.

Забудьте, что вы пишите код сайта, забудьте про пользователей, url-адреса, оформление страниц. Работайте с голыми данными: строками, числами, массивами, объектами.

class записи < public function создать_запись() <>punlic function удалить_запись() <> public function получить_запись() <> > 

Шаг 3. Понять, с чем имеем дело

Что такое запись? Что такое услуга? Что такое товар? Для вас, как программиста — это просто совокупность данных. В третьем шаге определяем, что это за совокупность.

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

Очевидно, запись — это заголовок и текст записи. Услуга и товар — название, описание и цена.

Компьютер — не очень умное создание, по сравнению с человеком, вы не сможете сказать ему: «а покажи-ка мне запись, ту, где про зелёного котёнка написано», поэтому ему всегда необходим какой-то уникальный код, чтобы он среди множества записей узнал именно ту, которую вы хотите.

Это либо порядковый номер (id), уникальный для каждой записи или некое, столь же уникальное, строковое значение.

Значит наша запись — это идентификатор записи (id), заголовок, текст.

Больше нам ничего не нужно.

Шаг 4. Определение необходимых знаний

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

Для действия «создать_запись» нужно знать заголовок и текст записи. Внутренний идентификатор нужен только компьютеру, поэтому пусть сам его и придумывает.

Для действий «удалить_запись» и «получить_запись» нужно знать только тот самый идентификатор записи, который был ей присвоен компьютером при создании.

class записи < public function создать_запись($заголовок, $текст) <>punlic function удалить_запись($идентификатор) <> public function получить_запись($идентификатор) <> > 

То, что получилось называется интерфейсом вашего класса/модуля/подсистемы.

Шаг 5. Определение результатов

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

• создать_запись: будет создана новая запись, а мы получим её идентификатор.
• удалить_запись: будет удалена конкретная запись, а мы получим сообщение ‘готово’
• получить_запись: получим нужную запись

• создать_запись: будет выброшено исключение.
• удалить_запись: будет выброшено исключение
• получить_запись: будет выброшено исключение

Для всех ситуаций, когда что-то не получилось поведение программы должно быть одинаковым во всех модулях/классах/подсистемах вашей системы. PHP предоставляет всего два варианта: trigger_error и throw new Exception. Можете придумать свой, но не стоит изобретать велосипеды, пока вы не научились ездить на существующих. throw new Exception — самый оптимальный вариант.

Читайте раздел «исключения» в официальном мануале.

Шаг 6. Снова с начала

В шаге первом, кроме создания системы управления записями, мы создали ещё класс и самой записи: class запись <>

Для неё нужно сделать тоже самое, что и для главной, те же самые шаги с 1 по 5.

Если вы всё сделали правильно, то у вас должно получиться что-то похожее.

class запись < public function получить_идентификатор() <>public function получить_заголовок() <> punlic function получить_текст() <> public function изменить_заголовок($новый_заголовок) <> public function изменить_текст($новый_текст) <> > 

Шаг 7. Пишем код

Теперь, когда всё создано можно приступать к кодированию. Если вы знакомы с PHP никаких проблем у вас не возникнет.

Сколько затратили времени? Совсем чуть-чуть, и ещё ощутите в будущем всюпользу от произошедшего.

То, что у вас получится в итоге скрывается под буквой M в страшной аббревиатуре MVC.

Заключение

Я не учёл много нюансов, их хватит на десять таких же статей, но базис для вашей разработки уже есть. Это — самые основы и это в любом случае лучше, чем мешать PHP с HTML в одном файле или плодить кучу функций по мере написания кода.

C M разобрались. Что касается V и C. Это тема для других статей. Поэтому вкратце. Если вы достаточно сообразительны, то другие статьи вам и не понадобятся.

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

V — изучите любой шаблонизатор: Smarty или Twig. Много споров ведётся про то использовать шаблонизаторы или нет, много убедительных доводов с той и с другой стороны. Правда в том, что для web-разработчика непростительно не уметь работать с шаблонизаторами. Поэтому осваивайте их, а потом уже откажетесь, если не понравится.

Как уже было отмечено выше, на русском языке почти нет достойный литературы на эту тему.
Единственную книгу, которую могу посоветовать прочитать: Стив МакКоннелл «Совершенный код».

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

Источник