Наскоро ми хрумна блестящата идея да направя скелет за всичките ми бъдещи проекти.Какво представлява този скелет? Значи, изграден е на модули, като има и ядро.Ядрото зарежда всички необходими модили за работата на “приложението” (скрипта), като модули за базата данни, member login, session, output, template и мн. други, които са все вътрешни модули.След това, зарежда външните модули (тоест, самият сайт вече), като определящото кой/кои модули ще се заредят е id-то на страницата.Всеки модул има достъп до вътр. модули и всичко е толкова лесно… Ето ви един пример:

Index.mod.php

class Index extends BaseModule {

function Index()
{
$this->BaseModule();
}

function act_Default()
{
global $app;

if (!$app->login->logged()) {
$app->tpl->display(’login.htm’);
} else {
$sql = “….”;
$app->db->query($sql);

if ($app->db->num_rows() < 1) {
$app->error($app->lang->get_text(’invalid_login’));
}

$user = $app->db->fetch_array();
}
}

function act_Login()
{
global $app;

if (($name = $app->input(’name’)) != NULL && ($pass = $app->input(’password’)) != NULL) {
if (!$app->login->member_login($user, $pass)) {….} else {…}
}
}
}

И тъй нататък

За мен успешното разделение е следното - Data Access Layer (връзка и манипулация на data storage) - за което препоръчвам ADODB - много прекрасно. Отделно ако ти трябват различни технологично ориентирани модули (IMAP връзка, комуникация с сървъри други, CC процесори, тем подобни…), те също се обособяват като класове. Да не забравим централизирана система за прихващане и обработка на грешки.

След това идва логиката на приложението, “бизнес обектите”, извличаме техните свойства от схемите, начертани предварително, които илюстрират които сме начертали процеса на работата на приложението… те вътрешно в себе си употребяват data access и каквото там се наложи.

Накрая идва UI (User Interface), което вече се грижи изцяло за поемането на взаимодействието с потребителя. Добре е да се ползва template model, макар че Smarty ми е супер смотан, като го сравня с asp.net (еххх…) но определено е нещо.

Има много за говорене, но определно php е труден за имплементиране на такъв тип архитектура… Лека полека ще стигна и дотам. Но най важното е да не се впускаш в частни случаи, за това си има наследяване за конкретен проект …

Друг проблем също е и самото разделяне на вътрешни и външни “модули” - малко объркващо, но няма как…

Определено изграждането на един общ “скелет” е добра идея, спестява доста труд и е лесно за ъпдейтване (просто се заменят файловете).

Мисля си, какво ще стане, ако примерно този “скелет” се хоства на дадено място и е базов за всички следващи проекти? Възможно ли е, как ти се струва тази идея? При една добра капсулация на данните няма да се налага ъпдейт на сайтовете, които ползват този “скелет” и ако има промяна, примерно в бързодействието, това ще се отразява навсякъде.

Стига толкова от мен, замечтах се вече, личи ми ) Поздрави и ВЕСЕЛИ ПРАЗНИЦИ НА ВСИЧКИ Пожелавам ви никога повече спам

- Поддръжка на debug и release състояние (в едната е ясно че бълва грешките директно в страницата)
- Бърз и лесен механизъм за уведомяване за инциденти (например най неангажиращото е изпращане по мейл, обаче ако сте 30 човека е добре като идея да репортва в някаква централизирана bug tracking система)
- Възможност за отбелязване на “проблеми” и “потенциални заплахи” при оперирането на системата (363 коментара за 1 минута например не е бъг, но трябва да бъде отразен).

Microsoft *заляга да не го пребият с камъни* са разработили exception management app block за .net -
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/emab-rm.asp

според мен подходът им (макар и доста усложнен) е правилният. Архитектурата на този “блок” може да се опрости и изгради на php. Да не забравяме, че оттам нататък всички останали парчета от кода трябва да се съобразяват с наличието на този блок и да не обработват грешките “на парче”, също и да “хвърлят” грешки ако се наложи. (PHP справка - trigger_error). Предвид излизането на php 5 (където вече има try catch finally, ако не се лъжа разбира се) може да се очаква error handling историята да стане малко по-културна.

За общия скелет - да, идеята е добра. Предимно ако разполагаш със собствен сървър. Дори е заложено в php енджина - обща include директория, където сложените неща са достъпни навсякъде. Под .net си имаш GAC - global assembly cache, пак със подобна идея.

И за финал да подчертая дебело, че изграждането на такъв скелет никак, ама никак не е лесна работа. Оценявам го като “висш пилотаж” предвид леките проблеми при употребата на ОО PHP…

Не е кой знае какво, но за малки неща може да се употреби без всякакво замисляне