Saturs
Pajautājiet man, kuru ietvaru izmantot, un man, iespējams, radīsies kašķīgs vecas sievietes brīdis un pastāstīšu, ka visi ietvari ir tikpat slikti kā viens otram. Kas nenozīmē, ka tie visi ir slikti, tieši tā, bet PHP mums ir neiedomājami liels ietvaru skaits (parasti minēts kā N + 1, kur N ir PHP izstrādātāju skaits pasaulē), un, iespējams, tiem visiem bija jēga personai, kas tos izgudroja.
Rāmju izvēle, iespējams, ir labāka nekā mēģinājums izmantot tikai vienu ietvaru neatkarīgi no tā, ko tieši jūs mēģinājāt uzbūvēt, jo tas ir “labākais” (neatkarīgi no “labākā” mēra). Šī ietvara piedāvājumu izvēle nozīmē, ka jūs varat izvēlēties kaut ko, kas atbilst projekta vajadzībām, un tas pat varētu būt dokumentēts. Jebkuras platformas ietvari patiešām ir paredzēti, lai nodrošinātu struktūru, atkārtoti izmantojamus moduļus un bibliotēkas, un parasti izvairās no visiem garlaicīgajiem un atkārtotajiem uzdevumiem, kas saistīti ar vienas un tās pašas funkcionalitātes izveidi atkal un atkal. Piemēram, veidojot CMS, kaut kas man jāapstrādā un jāapstiprina formas lauki; ja tas tiek atstāts manā ziņā, es varētu palaist garām kaut ko svarīgu, un es labāk gribētu darīt katra projekta elementus, kas ir savādāk, nevis tie, kas katru reizi ir vienādi!
Pilnas kaudzes ietvari
Pilna kaudzes ietvari, piemēram, Zend Framework, var būt jauka vieta, kur sākt izstrādātāju bez lielas arhitektūras pieredzes. Tas dod labu struktūru, uz kuras var piekārt jaunu lietojumprogrammu, un ap to ir laba ekosistēma - daudz grāmatu, apmācību un arī dažas pamatotas dokumentācijas. Ja jūs mēģināt izveidot lielu lietojumprogrammu, kuru uzturēs daudz cilvēku, populāra, visaptveroša sistēma, visticamāk, būs laba izvēle, jo tā diktēs diezgan lielu struktūru un būs labi zināma un saprotama.
Struktūra, kas palīdz šķirt, vienmēr ir laba; savas karjeras sākumā es strādāju ar dažiem ļoti jaunākajiem izstrādātājiem un mēģināja iemācīt MVC (Model View Controller) modeli, kas tajā laikā bija salīdzinoši jauns. Mēs pieņēmām lēmumu izmantot Smarty skata slānī; daļēji, lai dizaineri varētu vieglāk strādāt ar veidnēm, un daļēji tāpēc, ka, kad kāds pienāca pie mana galda un teica: "Kā man X darīt ar Smarty?" Es varētu teikt "nedarīt X skatā!" (deviņas reizes no 10, tā bija atbilde). Rāmju esamība palīdz mums atrast tādu pašu nošķiršanu citās mūsu lietojuma daļās. Daudzi no viņiem atbalsta integrāciju pret veidņu slāni, piemēram, Smarty vai manu jauno iecienītāko Twig, lai jūs varētu ņemt šos rīkus sev līdzi, neatkarīgi no tā, kuru sistēmu jūs izvēlaties.
Vieglāk noslogot
Ir daudz vieglāku ietvaru nekā Zend Framework, piemēram, es diezgan daudz strādāju ar CodeIgniter. Vai tas ir tikpat visaptverošs un izturīgs kā Zend Framework? Nē, tā nav. Bet tas ir noderīgs palīgs, kas ļauj ātri izveidot lietojumprogrammu. Kopumā ietvarus ar mazāku “palīga” funkcionalitāti var vieglāk orientēties, jo ir daudz acīmredzamāk, kā skaņdarbi iet kopā. Nepazīstamā sistēmā (man tas ir gandrīz viss) tieši ar automātiskajiem bitiem ir grūti strādāt un atkļūdot.
Šī “pazaudēšanas jaunā sistēmā” sajūta ir neizbēgama un pilnīgi nomākta; pat pieredzējis izstrādātājs jūtas kā iesācējs, kad nezina, kā kaut kas darbojas. Ja jums patiešām nav paveicies, būsiet izvēlējušies ietvaru, kura IRC kanāls jums pateiks, ka arī jūs esat idiots! Šī ir ļoti negatīva sākotnējā pieredze, kas daudziem cilvēkiem liek izmantot jaunu sistēmu vai to vispār pieņemt, un ļoti nedaudzi ietvari labi palīdz jauniem lietotājiem pārvarēt šo sākotnējo šķērsli.
PHP mums ir arī daži ietvari, kas patiesībā nav tādi, kādos es parasti lietoju šo vārdu. Mums ir daži jauki komponentu ietvari; bibliotēku kolekcijas, kas paredzētas lietošanai pēc vēlēšanās un jauki spēlēšanai kopā, piemēram, Zeta Components (iepriekš eZ Components) un Symfony Components (vai esat redzējuši viņu vietni? Viņi iegūst balvu par labāko mākslas darbu!). Vislabākais un nepietiekamākais no tiem, protams, ir paša PHP piedāvātais PEAR un PECL piedāvājums - kaut kā tie aizmirstas šajā drosmīgajā jaunajā ietvaru pasaulē.
Mikrorāmji
Mikrorāmji ir jauna tendence PHP; tie ir īpaši viegli piedāvājumi, kas tikai palīdz jums ātrāk salīmēt lietas. Labs piemērs ir Slim, kas ir ļoti ātri un vienkārši lietojams un saprot RESTful jēdzienus. Tās pamatā ir “maršrutu” ideja, kas ir URL raksti. Jūs reģistrējat maršrutu un veicat atzvanīšanu, kas jāizsauc, kad tiek pieprasīts šis URL.
Lielākā daļa PHP izstrādātāju pieņem sistēmu un turas pie tās, pretējā gadījumā viņi var izmantot vienu darbā un otru savam vaļaspriekam vai atvērtā pirmkoda projektiem. Par "labāko" izmantojamo sistēmu ir maz vienprātības, tāpēc visi vienkārši pieturas pie tā, ko zina, un rezultāts ir paralēla milzīga skaita ietvaru izstrāde! Man patīk, ka ir izvēle, no kuras izvēlēties, bet vai es pieminēju, ka viņi visi ir tikpat slikti kā viens otrs?
Ja jūs zināt Zend Framework, jūs galu galā raksturojat sevi kā Zend Framework izstrādātāju; jums nebūtu ērti rakstīt citā sistēmā, kamēr jums nebūtu iespējas ar to iepazīties, un jūs, iespējams, neatceraties daudzas neapstrādātas PHP funkcijas lietām, ja tās bieži neizmantojat. Šī ideja, ka mēs esam kļuvuši par specifiskiem izstrādātājiem, kas strādā tikai virs abstrakcijas slāņiem, PHP ir mazliet dīvaina. Galu galā šī ir valoda "tīmekļa problēmas risināšanai". Tas ir rakstīts C un pati par sevi ir ātra, viegla valoda ... nodrošinot, ka negaidāt, kamēr darbosies liels ietvara sāknēšanas process! No šī konteksta parādījās MicroPHP manifests, kuru uzrakstīja cilvēks, kuru mēs saucam par Funkatronu (lai gan viņa vārds patiešām ir Eds Finklers). Tā ir virkne paziņojumu, kuros teikts, ka ir pareizi izveidot vairākus savstarpēji izmantojamus mazus moduļus, ka lielāks nav labāks un ka Java dzīve ir pārāk īsa - pat ja tā ir rakstīta PHP.
