Яка хороша (охайна) архітектура в програмуванні простого веб-сайту, наприклад, контактної книги?

Коли я будую простий веб-сайт, наприклад, книгу контактів, де я можу додавати, видаляти та оновлювати контакти, я створюю index.phpфайл, у якому користувачеві, якщо він не ввійшов у систему, пропонується ввести пароль, а якщо він введе правильний пароль, він призначив сеанс і може робити певні речі із контактами.

У мене два файли:

1. Перший ( contacts.php) - це показ HTML-коду. Над HTML-кодом я включаю другий файл і створюю клас.
2. Другий ( contacts_class.php) містить всі способи додавання, видалення та оновлення.

Я думаю, що це нормально, але коли мова йде про реалізацію великого проекту, як мені це зробити? Чи потрібно створювати папки для кожної сторінки та вносити до них файли (наприклад, вище, HTML та клас), і як це робити? Яка хороша та акуратна архітектура для створення великих проектів, які кожен інший програміст розумів би ідеально?

Ви поставили дуже цікаве і принципове питання. Питання щодо масштабної архітектури проектів та організації структури папок (що є вторинним для архітектури).

На сьогодні найпоширенішим підходом до побудови рамкової архітектури CMS є використання шаблону MVC. Є кілька хороших статей про створення власних каркасів MVC, одна з них - Створення MVC Framework з PHP .

MVC означає Модель, Вид, Контролер. Ви можете називати ці підходи все, що завгодно - MVC, HMVC, MVP. Суть полягає у виділенні окремих компонентів вашої системи. "Контролер" отримує дані з "Моделі" та надсилає їх до "Перегляду", який надає остаточний HTML. Ви вже реалізували "V" у вашому contacts.phpта "MC" у своєму contacts_class.php. Отже, ви виділили вигляд від моделі та контролера. Тепер ви можете легко змінити свій "Вид", залишивши недоторканими інші частини.

Я не пропоную вам сліпо слідувати схемі MVC, MVP або будь-якого іншого типу "MV". Це питання доцільності, ефективності та смаку.

Загальна динамічна програма для веб-сайтів може включати такі компоненти, як:

• Точка входу, скажімо index.php
• Бібліотеки / класи-помічники
• Маршрутизатор запиту
• Модулі, компоненти або контролери
• Двигун шаблону або, можливо, окремі види

Справжня веб-програма може включати будь-які інші компоненти, такі як обробники подій, диспетчери подій та гачки, але це насправді нюанси. Ну, дозвольте представити його так, як я хочу його представити:

Загальна рамкова операція:

1. Запит браузера надсилається безпосередньо до виконуваної точки вводу / script ( index.php).
2. Сценарій точки введення завантажує бібліотеки-помічники, класи та виконує деяку подальшу ініціалізацію нашого програмного середовища.
3. URL передається екземпляру маршрутизатора запиту. Цей крок може бути частиною кроку 2.
4. Маршрутизатор запиту аналізує URL-адресу та передає операцію певному компоненту, модулю чи контролеру.
5. Компонент (або контролер) обробляє маршрутизований запит і передає дані в подання для надання.

Відповідна структура папок проекту показана на схемі.

Я б запропонував вам вивчити, як реалізуються інші рамки. Рекомендовані CMS / фреймворки для початку - CodeIgniter, OpenCart, Joomla 1.5 та Tango CMS.

Щоб отримати уявлення про питання, які потрібно задати, і які рішення доступні, я рекомендую книгу " Шаблони архітектури прикладних програм підприємства " Мартіна Фаулера. Ви можете отримати уявлення про те, що є в книзі, прочитавши його веб-сайт

Будь ласка, майте на увазі, що книга вже досить давня (на ІТ-майданчику), але багато принципів все ще діють, або ви повинні навчитися їх вчитися. (Це мало сенс?)

(Програмне забезпечення) Архітектура - це дуже широкий предмет, не сподівайтеся на срібну кулю, але завжди більше питань і більше сумнівів, поки не закінчаться час і гроші, і вам доведеться дотримуватися найкращого рішення поки що.

Перш за все, погляньте на добре розроблений проект. Wordpress - дуже акуратний приклад структури коду: його зрозуміти просто, але пропонує багато "підключення". Тож Wordpress легко сприйняти за допомогою "підключення".

По-друге, дуже простий спосіб перевірити свою архітектуру - це спроба написати блок-тест. Наприклад, якщо у класу "Карткова колода" є метод "перетасовування ()", ви повинні мати можливість створити колоду картки заздалегідь заданого розміру (тобто 5 карт 1,2,3,4,5), викликати перетасування та підтвердити в простий спосіб отримання результату (id 1,4,2,5,3)

Ви повинні вміти це робити, не інстанціюючи цілі класи проекту, і тест повинен бути дуже чистим для читання.

Якщо ви не можете цього зробити, потрібно додати шари між класами, реструктурувати їх, поки не з’явиться простий спосіб це зробити.

Потім повторіть цей крок для всіх основних класів вашого проекту.

І останнє, але не менш важливе: хороший архітектор міг би бути "ледачим" на не надто основних класах (справа в економії: дуже добре спроектовані речі коштують занадто дорого в реальному світі).

Гарною архітектурою для масштабних проектів є MVC (Model View Controller): http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Однак, чи зрозуміють це інші програмісти, це зовсім інше питання. MVC може отримати складний характер і іноді є надмірним для малих проектів. Однією з переваг цього є те, що він масштабується легко.

Якщо я правильно розумію ваше питання, ви говорите про структуру папок проекту, а не про архітектуру. Якщо моє розуміння правильне, читайте далі; інакше відредагуйте своє запитання або поставте коментар, і я відповідно відредагую свою відповідь.

Розробляючи програму, відповідаючи на деякі основні питання, такі як (що? І кому?), Нам потрібно визначити компоненти та класифікувати їх на основі функціональності \ обов'язків. Я знаю два основних способи. Ви можете класифікувати компоненти на основі, використовувати випадки, якими вони обробляються (наприклад, логін, пошук тощо) або класифікувати на основі ресурсів (Об'єкти ..). Перший спосіб називається орієнтованим на діяльність, а другий називається орієнтованим на ресурси. Традиційно більшість програм класифікують компоненти на основі діяльності (оскільки дизайнери знайшли це, легко переносячись із проблемного домену в домен рішення).

Після того, як класифікація компонентів буде визначена, нам потрібно визначити класифікацію на основі рівнів. Типовий веб-додаток матиме рівень перегляду рівня, модельного рівня та рівня контролера (MVC). Звичайно, можуть бути і більш складні програми. (більшість програм у реальному світі є більш складними, ніж це просто).

Після виявлення цих двох таксономій я буду створювати папки верхнього рівня, що ідентифікують кожен рівень. (Інтерфейс користувача, контролер, послуги, утиліти тощо). Під кожними папками високого рівня я буду створювати дочірні папки на основі функціональності та ресурсів (Project - / EditProject - / SearchProject тощо). Ідеально функціональна класифікація буде багаторівневою.

Є хороші архітектури і погані архітектури, проте срібних куль немає. Архітектура повинна відповідати поточним і максимально можливим майбутнім вимогам.

Хорошим керівним принципом є те, щоб переконатися, що кожну частину програми можна змінити з мінімальним впливом на інші частини та що кожна частина має автоматизований блок повного покриття та інтеграційні тести.

Архітектура полягає в тому, щоб переконатися, що ви можете продовжувати розвиватися в довгостроковій перспективі. Для більш великих застосувань це включає компроміси між тим, щоб зробити речі незалежними, щоб багато людей могли працювати одночасно і уникати дублювання (DRY), щоб проект міг бути спритним. Проекти PHP, як правило, зосереджуються на тому, щоб зробити речі незалежними та мати велику кількість дублювання.

Щоб добре відчути іншу крайню позицію, погляньте на Приморський

Якщо ви не знаєте, як структурувати великий проект, вам слід запозичити дизайн / архітектуру інших людей, використовуючи одну з кількох хороших PHP-фреймів. Я б рекомендував CakePHP, CodeIgniter або Symfony. Всі вони реалізують модель Model, View, Controller, MVC patten, яка добре працює в веб-розробці, всі вони досить легкі і прості в навчанні.

Ознайомившись із однією з цих рамок, ви, можливо, зможете сконструювати власну структуру для вашого конкретного проекту, але якщо ви тільки починаєте, я став би на роботу інших, а також винаходити колесо.

MVC - це найбільш часто використовувана архітектура, яка, як доведено, вирішує більшість проблем. Хороша архітектура матиме такі функції (та більше, оркурс)

1. Він може бути випробуваним в одиниці
2. Розділення проблем
3. Кілька народів зможуть працювати над цим без будь-якого зіткнення.
4. Її можна продовжити без особливих проблем
5. Це може бути масштабованим. Що стосується великих проектів, масштабність буде головним питанням. Оформити замовлення Kohana Framework, яке добре написано і його можна дуже масштабувати

перш ніж писати будь-який виробничий код, пройдіть 2 тижні (ночі :) і прочитайте цю книгу. Це надовго змінить вашу думку про архітектуру програмування, доповіді та пакетування.

Спритні принципи, зразки та практики C # від Prentice Hall

Приклади є в C #, але їх легко читати, це не про те, як написати правильний синтаксис коду, а про те, як мислити як програміст.

Я обіцяю, що ви збережете його на своєму найбільш доступному місці на своєму ПК, і ви будете вражені тим, що ви програмували, не знаючи про це. Це змістить ваше мислення.