Поскольку PHP-приложения становятся все более и более сложными, легко может оказаться запутанный беспорядок в коде, который делает обслуживание практически невозможным. Применение концепции многоуровневых приложений может помочь облегчить некоторые трудности в обслуживании сложных приложений.
Что вы подразумеваете под многоуровневыми приложениями?
Многоуровневое программирование — это практика разделения различных компонентов, идей или языков друг от друга.
При разработке интерфейса многоуровневая разметка будет использовать внешние таблицы стилей и JavaScript.
Связывая файл CSS, а не встраивая стили в HTML-разметку, легче изменить
форматирование ваших сайтов, потому что теперь вся информация о стилях удобно хранится в одном месте, отдельно
из разметки документа. И несколько HTML-страниц могут использовать один и тот же файл CSS, весь ваш сайт
можно обновить по стилю, просто изменив одну строку CSS.
В серверной разработке применяются те же правила, но мы имеем дело с разными компонентами. В общих чертах, мы
Рассматривая три уровня: База данных (хранение и извлечение данных), Бизнес
(обработка и обработка данных) и уровни представления (как данные отображаются).
Почему это должно меня волновать?
Это может быть не сразу очевидно, но разделение ваших приложений на многоуровневую структуру приведет к огромным
влияние на способность вашего кода измениться в будущем. Например, если у вас настроена система ведения блога, и
возникает необходимость создать RSS-ленту для блога, а правильно многоуровневое приложение позволит вам просто
настройте шаблон RSS, затем вызовите базу данных и бизнес-функции, которые вы уже написали.
С другой стороны, если ваш клиент вдруг решил, что PostgreSQL был лучшим выбором для их организации
чем MySQL, вам придется только переписать функции базы данных, не затрагивая бизнес или
логика представления приложения.
С точки зрения повторного использования, вы можете иметь несколько функций базы данных (поддержка MySQL, PostgreSQL и
Oracle, например), который можно легко внедрить в новые развертывания вашего приложения, используя всего несколько
строки кода в одном месте, а не редактирование нескольких строк кода в нескольких функциях.
Неправильный путь
Для начала давайте возьмем довольно простую задачу — вытащить заголовок и основной текст записи из базы данных,
создать сокращенную версию записи и поместить данные в разметку HTML — и перейти к этому в
совершенно неверный путь. В следующем коде мы напишем одну функцию для выполнения всех наших
задания:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
function displayEntry()
{
$entryDisp = NULL;
// Get the information from the database
$sql = «SELECT title, entry FROM entries WHERE page=’blog'»;
$r = mysql_query($sql) or die(mysql_error());
while($entry = mysql_fetch_assoc($r)) {
$title = $entry[‘title’];
$text = $entry[‘entry’];
// Create the text preview
$textArray = explode(‘ ‘,$text);
$preview = NULL;
for($i=0; $i<24; $i++) {
$preview .= $textArray[$i] .
}
$preview .= $textArray[24] .
// Format the entries
$entryDisp .= <<<ENTRY_DISPLAY
<h2> $title </h2>
<p>
$preview
</p>
ENTRY_DISPLAY;
}
return $entryDisp;
}
|
Этот код выводит HTML-разметку по следующим строкам:
|
01
02
03
04
05
06
07
08
09
10
11
12
|
<h2> Entry One </h2>
<p>
This is the shortened description of entry number one.
displays the first 25 words of the entry and then trails
off with an ellipsis…
</p>
<h2> Entry Two </h2>
<p>
This is the shortened description of entry number two.
displays the first 25 words of the entry and then trails
off with an ellipsis…
</p>
|
Хотя это может показаться логичным, на самом деле это действительно нежелательно. Давайте рассмотрим, что делает это
код менее чем оптимальный подход.
Проблема с этим подходом
Плохая разборчивость — этот код разбавлен. Его назначение, хотя и задокументировано в комментариях
(вроде) трудно различить. Если вы написали это, а затем вернулись к нему через шесть месяцев, это не было бы мгновенно
Понятно, что происходит, что означает потерю нескольких секунд / минут, пытаясь интерпретировать ваш собственный код.
Слишком узкий фокус — эта функция ограничена своей спецификой: запрос к базе данных работает только для одного типа записи;
создание предварительного просмотра текста жестко запрограммировано в функции; форматирование зависит от типа записи
отображается Чтобы создать немного иную реализацию этой функциональности, мы были бы вынуждены
создайте вторую функцию, которая выглядела бы почти одинаково , даже если все, что нам нужно было изменить, это число
слова в текстовом превью.
Недостаток масштабируемости — это довольно тесно связано с идеей быть слишком узким в фокусе; если мы хотим добавить больше функциональности (например,
как ссылка или изображение), наша функция станет больше и сложнее в управлении. А что если мы хотим добавить
условия, которые влияют на отображение записи? Легко увидеть, как такое программирование позволяет коду
быстро становятся растянутыми и неуправляемыми.
Большая проблема: объединение базы данных, бизнес и логика отображения
Это широкая проблема, которая вызывает все вышеупомянутые проблемы.
Объединив все три нашей логики
типов, мы получаем узкий, грязный, сложный в управлении, почти невозможный для повторного использования код.
Представьте себе приложение, в котором каждый тип отображения (RSS-канал, предварительный просмотр записи, полное отображение записи и т. Д.) Был создан с
функция, подобная приведенной выше, с доступом к базе данных, бизнес-логикой и логикой представления, написанными вместе.
Теперь представьте, что на сайте есть девять страниц, каждая из которых имеет свои собственные функции отображения и предварительного просмотра.
Даже если мы предположим, что приложение действительно простое и на каждой странице сайта есть только две функции, мы по-прежнему
просматривая почти двадцать функций, которые необходимо будет обновить, если изменения потребуются.
Улучшение кода
Чтобы улучшить приведенный выше код, мы распространим различные типы логики на несколько функций. Если все сделано правильно, мы
должен заканчиваться набором многократно используемых, легко понимаемых функций, которые складываются для выполнения различных задач.
Для начала мы спланируем необходимый функционал, чтобы получить лучшее представление о
как это должно быть построено:
- Получить столбцы записей и заголовков для данной страницы из таблицы «записей» в базе данных
- Сократите основную часть записи для предварительного просмотра из 25 слов и добавьте многоточие
- Вставьте данные в теги HTML для отображения в браузере пользователя
Как видите, наш план четко определяет базу данных, бизнес и уровень представления. Мы можем сейчас
написать функции для выполнения каждого из этих шагов с относительной легкостью.
Шаг 1 — Уровень базы данных
Чтобы получить информацию из базы данных, мы напишем очень простую функцию. Поощрять хорошее кодирование
на практике, я собираюсь использовать расширение MySQL , но
Я не собираюсь концентрироваться на том, как это работает. Если вы еще не используете его, я бы посоветовал вам изучить MySQL или
аналогичное расширение (т.е. PDO ) для защиты ваших запросов MySQL от
инъекционные атаки .
Итак, давайте перейдем прямо в код:
|
1
|
function getDataFromDB($page) { /* * Connect to a MySQL server */ $mysqli = new mysqli(‘localhost’, ‘user’, ‘password’, ‘world’);
|
Если вы разбиваете, что делает эта функция, мы буквально просто запрашиваем
два столбца (заголовок и запись) из нашей таблицы (записи), затем сохраняются все записи
в многомерном ассоциативном массиве, который является возвращаемым значением
функция. Мы передаем один параметр, $ page, чтобы мы могли определить, на какой странице мы находимся
захват информации для. При этом мы создали функцию, которая будет работать
для каждой страницы нашего сайта (при условии, что все они имеют поля ‘title’ и ‘entry’).
Обратите внимание, что наша функция ничего не делает для обработки данных; это просто действует
в качестве курьера, собирая запрашиваемую нами информацию и передавая ее
идет дальше Это важно, потому что, если бы он сделал больше, мы бы в
сфера бизнес-логики.
Почему важно отделить бизнес-логику от
логика базы данных?
Короткий ответ — это то, что он позволяет для базы данных
абстракция, что по сути означает, что данные могут быть перенесены из MySQL
в другой формат базы данных, такой как PostgreSQL или Oracle, все без
изменение функций обработки данных (бизнес-уровень), поскольку результат будет
по-прежнему просто многомерный ассоциативный массив, содержащий записи с
заголовок и запись столбца, независимо от того, какую базу данных мы используем.
Шаг 2 — Бизнес-уровень
С данными, загруженными в наш массив, мы можем начать обработку информации в
удовлетворить наши цели. В этом примере мы пытаемся создать предварительный просмотр записи. В
В первом примере длина предварительного просмотра была жестко запрограммирована в функции,
что мы решили, это плохая практика. В этой функции мы передадим два параметра
к нашему коду: текст для обработки и количество слов, которые мы хотим отобразить как
наш превью.
Давайте начнем с рассмотрения функции:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
function createTextPreview($text, $length=25)
{
/*
* Break the text apart at the spaces and create the preview variable
*/
$words = explode(‘ ‘, $text);
$preview = NULL;
/*
* Run a loop to add words to the preview variable
*/
if($length < count($words)) {
for($i=0; $i<$length; $i++) {
$preview .= $words[$i] .
}
$preview .= $words[$length] .
} else {
/*
* If the entry isn’t as long as the specified preview length, simply
* return the whole entry.
*/
$preview = $text;
}
/*
* Return the preview
*/
return $preview;
}
|
В приведенной выше функции мы просто проверяем, что количество слов в
запись больше, чем количество слов, которые мы хотим показать в нашем предварительном просмотре, затем
добавляйте слова во вновь созданную переменную $ preview по одному, пока мы не нажмем
целевая длина, после чего мы добавляем многоточие и возвращаем предварительный просмотр.
Как и на уровне нашей базы данных, мы держим код в пределах
бизнес-уровень. Все, что мы делаем, это создаем предварительный просмотр текста; здесь нет
взаимодействие с базой данных, и нет элементов представления, таких как HTML
разметки.
Шаг 3 — Уровень презентации
Наконец, нам нужно отобразить данные, которые мы получили и обработали. Для нашего
в целях, мы будем отображать его с предельно простой HTML-разметкой:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
|
<?php
$entries = getDataFromDB();
foreach($entries as $entry) {
/*
* Place the title and shortened entry text into two appropriately
* named variables to further simplify formatting.
* we’re using the optional $length parameter to create a 30-word
* text preview with createTextPreview()
*/
$title = $entry[‘title’];
$preview = createTextPreview($entry[‘entry’], 30);
?>
<h2> <?php echo $title;
<p> <?php echo $preview;
<?php
} // End foreach loop
?>
|
Идея этого кода проста: сначала загрузите записи, используя наш
функция базы данных, затем цикл по записям, сокращая текст записи
используя нашу функцию предварительного просмотра, а затем поместив заголовок и предварительный просмотр записи в
презентационная разметка.
Теперь, чтобы изменить макет предварительного просмотра записи, нужно всего две строки
HTML нужно настроить. Это гораздо менее запутанным, чем оригинал
функция, которая обрабатывает все три уровня.
Заключительные мысли о многоуровневом программировании
Я хотел бы отметить, что приведенный выше пример очень прост и предназначен только для
продемонстрировать концепцию многоуровневого программирования. Идея заключается в том, что, сохраняя
различные типы логики программирования разделены, вы можете значительно увеличить
удобочитаемость и удобство сопровождения вашего кода.
ПРИМЕЧАНИЕ: есть отличная статья
на TheDailyWTF.com обсуждают использование и неправильное использование многоуровневого программного обеспечения, и
замечательный комментарий на
статья, которая представляет различные мнения. Многоуровневые приложения чрезвычайно полезны, но также легко
неправильно понимать и чрезмерно усложнять, поэтому не забывайте тщательно планировать программное обеспечение перед сборкой, чтобы избежать
больше проблем, чем вы решаете.
Есть ли у вас мысли по поводу многоуровневых приложений? Какие шаги вы предпринимаете
максимально облегчить обслуживание и будущие изменения в коде, который вы пишете? Разрешите нам
знать в комментариях!
- Подпишитесь на RSS-канал NETTUTS, чтобы узнать о ежедневных новостях и статьях о веб-разработке.