2020-01-14
335
Об'єкти доступу до даних повинні забезпечувати об'єктно-орієнтоване API для доступу до реляційних баз даних. Це основа для інших, більш просунутих, методів доступу до баз даних, включаючи будівник запитів. При використанні об'єктів доступу до даних розробник повинен мати можливість використовувати MYSQL і масиви PHP. В результаті, це повинно бути найефективнішим способом доступу до БД. Для доступу до БД, розробник повинен спочатку підключитись до неї, створивши екземпляр класу, а так як підключення до БД розробнику може бути потрібно в різних файлах сценарію, то кращою практикою буде створення підключення до БД в якості компонента WEB системи. В результаті розробник повинен мати підключення в наступному вигляді: FW::$app->db. Де $db – змінна, яка містить конфігурацію підключення до БД, яку розробник повинен визначити перед її використанням. Під час налаштування підключення, розробник повинен обов'язково вказувати ім'я джерела даних (DSN) через параметр dsn. Наприклад, для MYSQL вказуватимуться наступні параметри: mysql:host=localhost; dbname=mydatabase. Де localhost – місце розташування БД відносно WEB системи, mydatabase – назва БД.
|
|
|
Розроблюваний фреймворк повинен мати наступні методи для роботи з схемою БД:
– createTable() – створення таблиці;
– renameTable() – перейменування таблиці;
– dropTable() – видалення таблиці;
– truncateTable() – видалення всіх записів в таблиці;
– addColumn() – додавання стовпця;
– renameColumn() – перейменування стовпця;
– dropColumn() – видалення стовпця;
– alterColumn() – перетворення стовпчика;
– addPrimaryKey() – додавання первинного ключа;
– dropPrimaryKey() – видалення первинного ключа;
– addForeignKey() – додавання зовнішнього ключа;
– dropForeignKey() – видалення зовнішнього ключа;
– createIndex() – створення індексу;
– dropIndex() – видалення індексу.
Також розробник повинен мати можливість отримати опис схеми таблиці через виклик методу getTableSchema(), який повинен повертати результат про назви таблиці, первинних ключах, зовнішні ключі та подібна інформація. Метод потрібен для того, щоб розробник орієнтувався в побудові схеми БД. Також, для роботи із запитами БД повинно, щоб існували стандартні методи роботи з запитами, а саме:
– Select – метод, який повинен надавати розробнику можливість вказувати стовпці, які повинні бути обрані, при цьому вони повинні бути вказані у вигляді масиву або рядки;
– From – метод, який повинен надавати можливість розробнику вказувати стовпці, з якими працює метод select;
– Where – метод, який повинен надавати розробнику можливість вказувати умови запитів;
– Order by – метод, який повинен надавати розробнику можливість сортування даних, отриманих з БД;
– Group by – метод, який повинен надавати розробнику можливість групування даних отриманих з БД;
|
|
|
– Having – метод, який використовується в поєднанні з оператором GROUP BY, щоб обмежити рядки, які повертає БД за допомогою умови даного методу (аналог методу Where). Даний метод повинен надавати вказані можливості маніпуляції з БД розробнику під час використання фреймворку;
– Limit та offset – методи, які повинні надавати розробнику можливість обмеження кількості отриманих записів на подальшу обробку або вивід в представлення;
– Join – метод, який повинен надавати можливість розробнику встановлення зв’язку між таблицями в запиті.
Також, розроблюваний фреймворк повинен надавати розробнику методи вибірки (select):
– all() – повинен повертати масив рядків, кожен з яких це асоціативний масив пар ключ-значення;
– one() – повинен повертати перший рядок запиту;
– column() – повинен повертати перший стовпець результату;
– exists() – повинен повертати значення, який вказує, що вибірка
містить результат (тобто дані по запиту існують);
– count() – повинен повертати результат COUNT (підрахунок кількості записів) запиту.
Розроблюваний фреймворк повинен надавати можливість створення WEB форм та випадаючих списків за допомогою можливостей розроблюваного фреймворку.
Проектування роботи з файлами
Фреймв о рк, який розробляється, повинен надавати можливість завантаження файлів. Система повинна надавати можливість створення файлів, які будуть відповідати за обробку завантажуваних файлів. Правила обробки файлів розробник буде створювати власноруч використовуючи методи фреймворку. Система повинна мати валідатор, який буде працювати з файлами та буде перевіряти файл на розширення, розмір, тип MIME (перевірка на тип файлу, наприклад: музичний файл, текстовий файл, відео файл та інше).
Посторінковий поділ даних
В тому випадку, коли потрібно буде відобразити занадто багато даних на одній сторінці, ця сторінка повинна розділятись на кілька частин, кожна з яких буде містити і відображати тільки частину даних за один раз. Такі частини називаються сторінками, а сам процес називається посторінковим поділом даних.
Висновки
Розроблюваний фреймворк може використовувати готовий PHP код, якщо він підходить до певної задачі. В сучасному світі є вже готові фрагменти коду, які можна інтегрувати в систему налаштовуючи під саму систему. Наприклад, щоб не створювати з нуля методи перевірки на валідацію (правильність) введеного паролю, можна використовувати готові методи перевірки з іншого фреймворку, наприклад Zend Framework, налаштовуючи під розроблювану систему щоб отримати оптимальний результат, що є гарною практикою та економить час на розробку самого фреймворку. Даний фреймворк, що розробляється, буде мати в собі кращі практики інших фреймворків, що були розглянуті в попередньому розділі та буде допрацьований додатковим власним кодом для того, щоб система повноцінно працювала.
РОЗДІЛ 3
АНАЛІТИЧНИЙ ОПИС ВЛАСНИХ ДОСЛІДЖЕНЬ
Результат досліджень
За допомогою мови програмування PHP, javascript, AJAX (фреймворк javascript), CSS, Bootstrap (фреймворк CSS), HTML та методу інтегрування окремих частин коду, які застосовуються в інших фреймворках, було створено власний фреймворк [1] [5].
Розроблений фреймворк отримав наступну структуру каталогів:
– Assets;
– Config;
– Controllers;
– Mail;
– Models;
– Vendor;
– Views;
– Web.
Каталог «Vendor» містить в собі основу системи, це власні розроблені файли з кодом та ті файли з кодом, які були використані з інших фреймворків.
В створеному фреймворку існують наступні методи:
– методи безпеки;
– методи встановлення власної теми (файли css, javascript, графічні файли);
– методи посторінкового розбиття даних (пагінація) на окремі частини (сторінки);
|
|
|
– методи завантаження файлів;
– методи перевірки на валідність (правильність) даних;
– методи побудови запитів та з’єднання до БД;
– методи роботи з віджетами;
– методи авторизації;
– методи роботи з відображеннями та макетами;
– методи маршрутизації (за умовчуванням, метод відображення домашньої сторінки та сторінки «about» (про нас), розробник в подальшому створює свої маршрути відносно створеної ним WEB системи).
За допомогою перелічених методів розробник зможе створювати повноцінні WEB системи. Також розробник зможе доповнювати фреймворк власним програмним кодом за власним побажанням.
Розробник може встановлювати фреймворк наступними способами:
– копіювання каталогу фреймворка;
– розпакування архіву в потрібну директорію.
Для перевірки того, чи правильно встановлений розроблений фреймворк, розробник може перевірити за допомогою браузеру просто вказавши доменне ім’я WEB системи. Отриманий результат повинен виглядати так, як вказаний на рисунку 2.1.
Нижче наведено приклад того, як розробник може створити свою WEB сторінку:
– спочатку створюється модель. Дані, отримувані від користувача, будуть представлятись моделлю класу EntryForm як показано нижче, який зберігатиметься у файлі models/EntryForm.php.
<?php
namespace app\models;
use Fw;
use Fw\base\Model;
class EntryForm extends Model
{
public $name;
public $email;
public function rules()
{
return [
[['name', 'email'], 'required'], // вказуються обов’язкові поля
['email', 'email'] // вказуються правила перевірки
];
}
}
Даний клас успадкований від класу Fw\base\Model, який є складовою частиною фреймворку і використовується для роботи з даними форм.
– другим кроком є створення дії. Необхідно створити дію entry в контролері site, яка буде використовувати нову модель. Код створення дії наведено нижче.
<?php
namespace app\controllers;
use Fw;
use fw\web\Controller;
use app\models\EntryForm;
class SiteController extends Controller
{
//...деякий код...
public function actionEntry()
{
$model = new EntryForm();
if ($model->load(Fw::$app->request->post()) && $model->validate())
{
// дані в $model успішно перевірені
// тут робимо щось корисне з $model...
|
|
|
return $this->render('entry-confirm', ['model' => $model]);
} else {
// або сторінка відображається вперше, або ж є помилка в даних
return $this->render('entry', ['model' => $model]);
}
}
}
Дія спочатку створює об’єкт EntryForm. Потім вона намагається заповнити модель даними із масиву $_POST. Якщо модель успішно заповнена, тобто користувач відправив дані з HTML-форми, то для перевірки даних буде викликаний метод validate().
Якщо все гаразд, дія зобразить представлення entry-confirm, яке покаже користувачу вказані ним дані. Якщо дані не передані або містять помилки, буде зображено представлення entry з HTML-формою та повідомленнями про присутні помилки перевірки даних.
Третім кроком буде створення представлення. Створюємо два файли представлення з іменами entry-confirm і entry, котрі зображаються дією entry з минулого кроку. Представлення entry-confirm просто зображає ім’я та адресу електронної пошти. Воно повинно бути збережене у файлі views/site/entry-confirm.php з кодом, який наведено нижче.
<?php use fw\helpers\Html;?>
<p>You have entered the following information:</p>
<ul>
<li><label>Name</label>: <?= Html::encode($model->name)?></li>
<li><label>Email</label>: <?= Html::encode($model->email)?></li>
</ul>
Представлення «entry-confirm.php» наведено на рисунку 3.1.
Рис. 3.1 – Представлення entry-confirm.php з відображенням даних
Представлення entry відображає HTML-форму. Воно повинно бути збережене у файлі views/site/entry.php з кодом, який наведено нижче.
<?php
use fw\helpers\Html;
use fw\widgets\ActiveForm;
?>
<?php $form = ActiveForm::begin();?>
<?= $form->field($model, 'name')?>
<?= $form->field($model, 'email')?>
<div class="form-group">
<?= Html::submitButton('Submit', ['class' => 'btn btn-primary'])?>
</div>
<?php ActiveForm::end();?>
Користувач WEB системи побачить сторінку з формою і двома полями для заповнення. Перед кожним полем є надпис, який вказує, яку саме інформацію слід вказувати. Якщо користувач натиснете на кнопку відправлення даних без самих даних або якщо введе в поле адресу електронної пошти в невірному форматі, то він побачить повідомлення про помилку біля кожного проблемного поля. Результат наведено на рисунку 3.2.
Рис. 3.2 – Представлення entry.php з подією відправлення пустої форми
Початкова перевірка даних проходить на стороні клієнта за допомогою JavaScript, і повторно перевіряється на стороні сервера (PHP). На випадок, якщо в браузері буде вимкнено JavaScript, то перевірка буде проходити на стороні сервера, як показано в методі actionEntry(). Це дає впевненість в тому, що дані коректні за будь-яких обставин. Перевірка на стороні клієнта – це зручність для самого клієнта, щоб він міг не оновлюючи сторінку отримати інформацію про стан відправленої форми. Для безпеки системи, перевірка відправленої форми даних на стороні серверу є обов’язковою. Методи, які використовуються для відображення і обробки даних допомагають розробнику використовувати менше коду для естетичності стилю програмування та значно зекономити час на реалізацію. Окрім того, код стає більш зрозумілим по тій причині, що розробник візуально бачить загальну структуру коду не відволікаючись на інші елементи та код стає більш читабельним по тій причині, що назва методів є синонімами дії на англійській мові (PHP не використовує символи кирилиці для іменування змінних, методів та тому подібне).
В розробленому фреймворку використовується розбір URL на маршрути, цей процес називається маршрутизація. Фреймворк може представляти URL трьома способами:
– /index.php?r=post/view&id=100;
– /index.php/post/100;
– /post/100.
Спосіб представлення URL залежить від компоненту urlManager. Наприклад, для створення URL-адреси для post/view можна використовувати наступний код:
use fw\helpers\Url;
// Url:: to () викликає UrlManager:: createUrl () для створення URL
$Url = Url::to(['post/view', 'id' => 100]);
// результатом буде /index.php?r=post/view&id=100;
Приклад конфігурації підключення до бази даних і подальшої ініціалізації підключення вказується наступним кодом:
$config = [
'class' => 'fw\db\Connection', // тип конфігурації
'dsn' => 'mysql:host=127.0.0.1;dbname=exampledb', //тип, хост, назва
'username' => 'root', // логін до БД
'password' => '', // пароль до БД
'charset' => 'utf8' // кодування
];
$db = Fw::createObject($config); //створення об’єкту конфігурації
Конфігурації вказуються в каталозі /config. При цьому, змінна $db використовується в подальшому для маніпуляції з БД. Те, що підключення до БД реалізується окремим файлом, надає можливість розробнику змінити конфігурацію підключення затрачаючи на це мінімум часу з максимальною зручністю, так як не потрібно виконувати підключення до БД при кожному до нього зверненні.
Наступний код показує звичайну побудову запитів:
$rows = (new \fw\db\Query())
->select(['id', 'email'])
->from('user')
->where(['last_name' => 'Гребенюк '])
->limit(10)
->all();
Дана побудова запиту є аналогом запиту, вказаного нижче:
SELECT `id`, `email`
FROM `user`
WHERE `last_name` = 'Гребенюк'
LIMIT 10
Методи побудови запиту до БД потрібно вказувати в послідовності методів запитів самої БД. Тобто спочатку вказується метод select() і тільки після нього метод from() і т.д.
Для того, щоб система безпечно працювала з даними користувача, потрібно щоб дані були перевірені на правильність та на існування. Враховуючи модель даних які повинен заповнити користувач, можна перевірити ці дані на валідність скориставшись методом fw\base\Model::validate(). Метод повертає логічне значення з результатом валідації true/false. Якщо дані не валідні, помилку можна визначити скориставшись властивістю fw\base\Model::$errors, наприклад:
$model = new \app\models\ContactForm;
// заповнюємо модель даними користувача
$model->load(\Fw::$app->request->post());
// аналогічно наступному рядку
// $model->attributes = \Fw::$app->request->post('ContactForm');
if ($model->validate()) {
// всі дані коректні
} else {
// Дані не коректні: $errors – масив, який містить повідомлення про помилку
$errors = $model->errors;
}
Для того, щоб validate() дійсно працював, потрібно оголосити правила перевірки атрибутів. Правила для перевірки вказуються в методі fw\base\Model::rules(). У наступному прикладі показано, як правила для перевірки моделі ContactForm, потрібно оголошувати:
public function rules()
{
return [
// атрибут required вказує, що name, email, subject, body обов'язкові для заповнення
[['name', 'email', 'subject', 'body'], 'required'],
// атрибут email вказує, що змінна email повинна бути перевірена на коректність адресу електронної пошти
['email', 'email']
];
}
Якщо необхідно виконати декілька перевірок щодо кількох значень, розробник може використовувати fw\base\DynamicModel, який підтримує оголошення, як атрибутів так і правил. Його використання виглядає наступним чином:
public function actionSearch($name, $email)
{
$model = DynamicModel::validateData(compact('name', 'email'), [
//перевіряються змінні name та email на тип та кількість символів
[['name', 'email'], 'string', 'max' => 128],
//перевірка на коректність адресу електронної пошти
['email', 'email']
]);
//метод hasErrors() виконує перевірку на помилки в змінній $model
if ($model->hasErrors()) {
// перевірка на коректність завершилась помилкою
} else {
// перевірка на коректність пройшла успішно
}
}
Метод fw\base\DynamicModel::validateData() створює екземпляр DynamicModel, який визначає атрибути, використовуючи наведені дані (name і email), і потім викликає fw\base\Model::validate() з даними правилами. Перевірка на коректність даних проводиться на стороні клієнта (браузер), якщо у нього увімкнено виконання сценаріїв JavaScript.
Для відображення великої кількості даних, розробник може використовувати метод розділення інформації посторінково. Для виконання посторінкового виведення інформації потрібно розробнику:
– в дії контролера створити об'єкт посторінкового поділу даних і заповнити його даними. Наприклад:
function actionIndex()
{
$query = Article::find()->where(['status' => 1]);
$countQuery = clone $query;
$pages = new Pagination(['totalCount' => $countQuery->count()]);
$models = $query->offset($pages->offset)
->limit($pages->limit)
->all();
return $this->render('index', [
'models' => $models,
'pages' => $pages,
]);
}
– наступним кроком розробник в поданні виводить моделі для поточної сторінки і передає об'єкт посторінкового поділу даних в елемент нумерації сторінок. Наприклад:
foreach ($models as $model) {
// відображаються дані змінної $model
}
// відображаються посилання на інші сторінки
echo LinkPager::widget([
'pagination' => $pages ]);
Алгоритм авторизації
Фреймворк містить готовий коду авторизації в файлі «User.php». Спочатку користувач вводить логін і пароль в форму авторизації, якщо дані введено не вірно (наприклад, логін містить більше 255 символів або дані в форму не введені), то система за допомогою Ajax виведе користувачу повідомлення про помилку без оновлення сторінки. Якщо дані введено вірно, то вони відправляються на сервер для перевірки на вірність даних з його сторони. Якщо дані невірні, то система повідомляє користувача про помилку авторизації. Якщо дані вірні, то виконується запит на відповідність логіна та паролю, після чого виконується перевірка на існування користувача в системі. Якщо користувача в системі не існує, то він отримує повідомлення про помилку авторизації. Якщо існує, то отримує статус «авторизований». Алгоритм роботи авторизації зображений на рисунку 3.2.
Рис. 3.3 – Алгоритм авторизації
Алгоритм реєстрації
Для того щоб система виконала реєстрацію користувача, вона спочатку зчитує файл конфігурації «db.php» для підключення до БД, який знаходиться в каталозі «config». Якщо підключення БД до системи встановлено, то користувач отримує ім’я доступу, після чого виконується перевірка на існування користувача. Якщо користувач існує, то він отримує доступ до системи. Якщо не існує, то виконується реєстрація користувача та присвоюється йому ідентифікатор в БД та роль (гість, адміністратор і т. п.). В результаті користувач отримує доступ до системи. Алгоритм процесу реєстрації наведено на рисунку 3.3.
Рис. 3.3 – Алгоритм реєстрації
Висновки
Фреймворк, що був розроблений в ході виконання магістерської дипломної роботи, увібрав в себе кращі властивості наступних фреймворків:
– Zend Framework;
– Symfony;
– CodeIgniter;
– FuelPHP.
Розроблений фреймворк увібрав в себе від вище вказаних фреймворків схему розділення даних MVC та об’єктно-орієнтованість. Від Zend Framework та Symfony увібрав в себе компоненти валідації і форм. Від CodeIgniter увібрав в себе методи роботи з реляційною БД MYSQL. Від FuelPHP увібрав в себе методи маршрутизації.
Розроблений фреймворк відносно від Zend Framework кращий в тому, що він придатний для швидкої розробки WEB систем. Відносно від Symfony та FuelPHP кращий в тому, що він легко сприймається для розробників з базовими знаннями PHP, javascript, MYSQL, так як для виконання певних операцій фреймворк містить ціль виконання методів в своїх назвах. Відносно від CodeIgniter кращий в тому, що підтримує нові функці PHP.
Даний фреймворк є об’єднанням алгоритмів вище вказаних фреймворків. Він призначений для швидкої розробки WEB систем мовою PHP, також використовує Bootstrap, Javascript, Ajax, HTML, CSS та методи роботи з MYSQL. До створеного фреймворку було реалізовано додаткові методи роботи з БД, конфігураційні файли та віджети.
ВИСНОВОК
Темою магістерської випускної роботи (МВР) була розробка фреймворку для автоматизації створення WEB систем. В процесі виконання даної МВР були дослідженні роботи зарубіжних розробників WEB систем, а саме: Zend Framework, Symfony, CodeIgniter, FuelPHP. Також була досліджена наукова робота Бастрикіна В. В.: «Порівняльний аналіз адаптивних CSS фреймворків».
Метою розробки фреймворку було:
– об’єднання основних методів та компонентів з вище вказаних фреймворків в один;
– приведення синтаксису коду розробки на простий рівень зрозумілості;
– створення власних методів для простоти роботи з розробленою системою.
Створений фреймворк може бути використаний розробником для автоматизації створення WEB систем.
Розробник, який буде використовувати розроблений фреймворк, повинен мати базові знання з: PHP, JavaScript, HTML, CSS. Також розробник повинен володіти теоретичною інформацією про MVC (модель-представлення-контролер) та об’єктно-орієнтоване програмування.
В першому розділі була визначена термінологія та теоретична інформація, яка практично застосовується в розробці та використанні сучасних фреймворків. На етапі огляду аналогів системи були визначені проблеми, які повинен вирішувати розроблений фреймворк, а саме: підтримка сучасних PHP функцій, зрозумілість синтаксису розробки, простота у вивчені новачками, швидка розробка (після встановлення фреймворк вже готовий до розробки), робота з реляційною БД MYSQL.
В другому розділі було обґрунтовано вибір напряму досліджень, методи вирішення поставлених завдань до розробленого фреймворку. Також, була спроектована архітектура системи. Були визначені властивості, методи, система маршрутизації фреймворку та наведені кращі практики використання. Для взаємодії з БД були наведені методи роботи з її архітектурою та методи роботи з запитами до неї.
В третьому розділі були наведені результати дослідження, розробки фреймворку та наведені практики використання.
Протягом виконання МВР було визначено, що об’єднання кращого функціоналу різних систем в одну може дати кращий результат використання, якщо при цьому створювати єдиний зв’язок між елементами різних систем, інакше система працювати не буде. А для того, щоб зв’язок між елементами різних систем існував, потрібно створювати єдиний синтаксис використання. Також було визначено, що кращим синтаксисом використання PHP фреймворків є використання об’єктно-орієнтованого програмування.
