Архітектура / дизайн веб-додатків PHP [закрито]


20

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

  • Відокремлення заднього кінця від переднього кінця
  • Структура каталогів

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


Привіт! Найпоширеніша архітектура веб-додатків - MVC , для PHP та будь-якої іншої популярної веб-платформи. Однак, ви повинні прочитати наш FAQ . Хоча архітектура програмного забезпечення є темою, вам потрібно переглянути питання, щоб бути трохи більш конкретними. "Здорова дискусія про загальну архітектуру" не відповідає формату питань і відповідей на сайті.
yannis

Я є частим відвідувачем S / E Sites, я відчував, що на це питання ніхто не відповість, отже, коментар "обговорення". Дякую за покажчик MVC :)
Бред Морріс

Відповіді:


29

Приблизна схема архітектури останнього масштабного проекту, в якому я брав участь.

введіть тут опис зображення

Це лише базовий контур, адаптований із фактичних архітектурних документів та представлений таким чином, що нагадує типовий підхід n-ярусів у поєднанні з типовим підходом MVC . Як ви бачите, логічні рівні та рівні даних з'єднуються через сервісний рівень, а точніше API REST , який був натхненний Recess , менш відомою рамкою PHP.

Не винаходити колесо

Я працюю з трьома рамками:

  • Zend Framework

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

  • Кохана

    Кохана почався як вилка CodeIgniter, і це було достатньою причиною, щоб я не використовував її спочатку. Сьогодні вона переросла у міцну та елегантну основу, яка відрізняє себе один від одного, дотримуючись ієрархічного підходу MVC . HMVC дозволяє отримати більшу кількість модуляризації, ніж MVC . Для проекту на діаграмі я адаптував HMVC Kohana до ZF, але я почав використовувати Kohana для менших проектів і розглядав його як для більших.

  • CodeIgniter

    Я використовую його лише через спадковий проект, який я успадкував, якщо це можливо, уникайте.

Як вказували інші відповіді, ОРМ завжди корисний. Я широко використовую Doctrine , і вам слід поглянути на його абсолютно нові картографи для CouchDB та MongoDB . Масштабованість є необхідною у великих програмах, і ви повинні оцінювати рішення NoSQL .

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

Продуктивність

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

xdebug здебільшого відомий як налагоджувач, але також може служити профілером . Нещодавно я почав використовувати Zend Server, і я абсолютно обожнюю його функції відстеження коду . На жаль, вони не доступні у виданні Community , але xdebug є досить гідною альтернативою.

Якщо ви використовуєте Apache, не забудьте оптимізувати його . nginx і lighttpd - це, мабуть, кращий вибір , ефективність роботи, але я не використовував їх багато, і я не можу сказати.

Що стосується бази даних, то кешування запитів і результатів Doctrine творить чудеса, особливо в поєднанні з запам’ятовується . І звичайно, ми не можемо забути про передню частину. Команда Yahoo's Exception Performance зібрала широкий перелік найкращих практик . Я насправді не розробник передньої частини, але бачив дивовижні результати на сольних проектах.

Нарешті, PHP має абсолютно новий механізм збору сміття , який варто вивчити.

Безпека

Світ безпеки PHP, хоча б сказати, хаотичний. Я не експерт, тому ставтесь до таких як до загальних порад:

  • Відкрийте проект безпеки веб-додатків

    Тут є багато хороших речей, але для швидкого огляду слід почати з першої десятки списку . І досліджуйте PHP-рішення для цих загальних уразливостей.

  • Стек уразливості

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

Натовп на IT Security Stack Exchange може допомогти вам з більш освіченими відповідями.

Подальше читання


1
Чудова відповідь; чудова презентація; чудовий макет ... Чудова робота!
Динамічний

@Jae Дякую! Ви все це прочитали? : P Це трохи довго, мені було цікаво, чи варто трохи обрізати його.
янніс

Га, я спробував! ;-)
Динамічний

Насправді Янніс, у мене питання до вас. Нещодавно я дуже зацікавився PHP. Я сам намагався це навчитися, але у мене є проблеми. Також здається, що ти дуже добре працюєш із PHP :-). Ви б не хотіли поділитися трохи рекомендацій? Якщо так, я створять кімнату чату.
Динамічний

Саме таку відповідь я шукав! Це пекло багато інформації, яку потрібно взяти, я думаю, що хворий повинен зробити деякий поглинаючий і хитруючий протягом наступної години, але ти дав мені десь почати. Спасибі :)
Бред Морріс

1

Веб-сайт розробників IBM має величезну купу статей PHP , багато з них досить непогані. У них є ряд статей, в яких порівнюються веб-рамки PHP , та ще одна серія про веб-сайти, що використовують рамку CakePHP .

На старому веб-сайті "Онламп" O'Reilly є стаття про MVC в PHP . Автор цієї статті далі детально пояснив MVC .

Статті O'Reilly трохи старі, але вони вас змусять іти. Речі для розробників IBM справді хороші та охоплюють багато того, що ви просите.


1

Я працюю навколо PHP вже кілька років. Хоча я згоден з Яннісом, що це питання якимось чином відкрито, я думаю, я дав би вам декілька покажчиків. По-перше, як сказав Янніс, вам слід заглянути в MVC, щоб зробити це, дві рамки, які я можу порекомендувати, це CodeIgniter і Symfony . Перший - це легкий і дуже легкий для початку роботи, однак, вам може знадобитися додати кілька додаткових налаштувань, щоб приємно налаштувати роботу. Symfony - проект, розпочатий Фабієном Потенцьє який використовує багато моделей дизайну в інженерії програмного забезпечення, однак крива навчання набагато крутіша, ніж у CodeIgniter .

Тепер, по-друге, ви повинні вивчити підключення до бази даних, що приводить мене до двох найвідоміших рамок ORM для PHP, Doctrine та Propel . Особисто я люблю Propel і навіть писав про те, як налаштувати чисту установку Propel у додатку на основі CodeIgniter , однак Symfony більше входить у доктрину , але давайте скористаємося будь-яким. Якщо ви хочете ознайомитись ще з доктриною та пропелом , погляньте на це питання, яке я задав деякий час тому.

І, нарешті, ви повинні дивитися в рамки шаблонного, як Smarty , Dwoo або Twigg . Сматі - найстаріший і, отже, найстійкіший. Dwoo успадковує від Smarty і додає річ чи дві, щоб краще підтримувати OOP на PHP 5. Нарешті, Twigg - це шаблонна альтернатива за умови, що команда Symfony я цього не бачив, але якщо це походить від команди Symfony, це повинно бути добре .

Сподіваюся, цілий виступ має певний сенс, Девіде

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.