Jump to content
php.lv forumi

16 PHP Frameworku īss apskats


Aleksejs

Recommended Posts

16 PHP Frameworks To Consider For Your Next Project

Pirmās rindkopas tulkojums:

Kādēļ tērēt vērtīgo laiku, kodējot visu no nulles? Freimworka izmantošana ir lielisks veids, kā ietaupīt laiku un pūles jūsu nākamajā projektā - jums būs stingrs pamats uz kā sākt būvēt, būs iepriekšizveidoti moduļi, lai veiktu nogurdinošos kodēšanas uzdevumus, un ja patīk mācīties, šis ir lielisks veids kā apgūt kodēšanas labo praksi. PHP milzīgā popularitāte nozīmē, ka izstrādātājiem ir plašs freimworku klāsts no kā izvēlēties. Mēs esam pārliecināti, ka varat atrast starp šiem 16 tādu, kas apmierina jūsu vajadzības.

 

Ir ļoti īsi apskatīti:

Agavi

Akelos

CakePHP

CodeIgniter

eZ Components

Fuse

Horde

Kohana

PHP on Trax

PHPOpenBiz

Qcubed

Seagull

Symphpony

WACT

Zend

ZooP

Link to comment
Share on other sites

  • Replies 48
  • Created
  • Last Reply

Top Posters In This Topic

Manā pieredzē pagaidām nav bijusi nepieciešamība lietot kādu frameworku, jo viss ko esmu taisījis ir ļoti vienkāršs pēc savas būtības, kam īsti neatmaksājas izmantot frameworku. Taču interese par šo lietu ir un ik pa brīdim pasekoju līdzi to attīstībai.

Link to comment
Share on other sites

Jau kādu laiku lietoju CodeIgniter, ātri apgūstams un neuzspiež striktus nosacījums. Nezinu kā ir patreiz (kā pārējie ietvari attīstījušies), bet kādreiz tas arī skaitījās ātrākais.

 

Ļoti slikti, ka neuzspiež striktus nosacījumus. Vismaz kodēšanā, pierakstā, stilā, arhitektūrā tādiem ir jābūt! Zini kā var būt strikti nosacījumi, bet elastīga programma?

Link to comment
Share on other sites

Nepiekrītu.. Viens no ietvaru galvenajiem mērķiem ir paātrināt programmatūras izstrādes procesu. Jo vairāk ierobežojumi, kam jāpiemērojas, jo vairāk tie samazinās izstrādes procesa ātrumu un vietām tie arī ierobežo aplikācijas elastību. Tāpēc, manuprāt, daudz labāk ir definēt vadlīnijas, kuras ieviešot un pie kurām pieturoties tu saproti to jēgu un jūti to devumu.

Teiksim, pašos pirmsākumos, kad līdz ar šī ietvara apguvi, mēģināju apgūt arī MVC modeli. No sākuma neizpratu Modeļu (models) jēgu un būtību, tāpēc rakstīju (un CodeIgniter nespieda mani to darīt) visus vaicājumus kontroleros, nevis modeļos, līdz sapratu cik pārskatāmāku un lasāmāku kodu to izmantojot var iegūt.

P.S. protams viss atkarīgs no tā ko katrs no mums saprot ar terminu "strikti ierobežojumi"

Link to comment
Share on other sites

MVC kontekstā,

modeļi nav tikai tāpēc, lai būtu atsevišķš fails kurā rakstīt kveriju palagus.

Domā par modeļiem kā blokiem (ne vizuāliem) kurus līmē kopā kontrolerī, lai galā sanāktu vajadzīgā biznesa loģika.

Link to comment
Share on other sites

Ir sanācis padarboties ar Symphpony, totāls murgs. vai nu arī man nebija vajadzīgā saprašana. Bija viens projekts, mini firmas webs, paskatījos kā galvenais veidojis uz Symphpony bāzes, lol 3K lieku failu parastam firmas webam. :D

 

Ir reizes, kad lietot ir ok, ir reizes, kad to darīt nav jēgas. Jāskatās kam un kur.

Edited by foxsk8
Link to comment
Share on other sites

Nepiekrītu.. Viens no ietvaru galvenajiem mērķiem ir paātrināt programmatūras izstrādes procesu. Jo vairāk ierobežojumi, kam jāpiemērojas, jo vairāk tie samazinās izstrādes procesa ātrumu un vietām tie arī ierobežo aplikācijas elastību. Tāpēc, manuprāt, daudz labāk ir definēt vadlīnijas, kuras ieviešot un pie kurām pieturoties tu saproti to jēgu un jūti to devumu.

Teiksim, pašos pirmsākumos, kad līdz ar šī ietvara apguvi, mēģināju apgūt arī MVC modeli. No sākuma neizpratu Modeļu (models) jēgu un būtību, tāpēc rakstīju (un CodeIgniter nespieda mani to darīt) visus vaicājumus kontroleros, nevis modeļos, līdz sapratu cik pārskatāmāku un lasāmāku kodu to izmantojot var iegūt.

P.S. protams viss atkarīgs no tā ko katrs no mums saprot ar terminu "strikti ierobežojumi"

 

Tik vienkārši tas viss nav. Tas MVC ir izdomāts lai atvieglotu projekta uzturēšanu un attīstību, nevis tieši sākotnējo izstrādi pirmajam rezultātam. Strikti ierobežojumi ir vajadzīgi, lai kods būtu pārskatāmāks, loģiskāks, vienveidīgāks un veidots pēc paraugiem, noteikumiem. Neviens freimvorks parasti tik ļoti "nespiež" darīt tā un tā, bet vēlams jau no sākuma iemācīties darīt tā kā ir pareizāk darīt. Modeli uztver kā datu modeli - tas ir objekts, kur glabājas tavi dati. Kā tu viņu uzpildi un sapildi, tas ir biznesa loģikas jautājums, tu to vari darīt "data supplier" klasē, kas var būt kā kontrollera sastāvdaļa, pēc tam tu šo modeli izmanto savā view, lai vienkārši attēlotu datus.

Šitās lietas vienmēr ir vērts labi pārdomāt un pārskatīt, jo pēcāk tas tev ievērojami atvieglos darbu - tu zināsi - ā, šiten jāizdara tas un tas, tad man jāaiztiek tikai attiecīgais view un viss... Šeit vajag uzprogrammēt jaunus nosacījumus datu apstrādē ar jau esošiem esošie datiem - ok, pamainam kontroleri un viss aiziet, šeit mums vajag pievienot jaunu lauku datubāzē, ko pēc tam izmantot kodā - ok, uztaisam datubāzē un modelī šo jauno lauku, pēc tam bez problēmām izmantojam jebkur.

Link to comment
Share on other sites

  • 4 months later...

Runājot par frameworkiem tieši uz php, ir pamēģināts, piemēram, ZendFramework. Pateikšu godīgi - tas izskatījās nevis pēc mēģinājuma atvieglot darbu un uzlabot tā kvalitāti, bet gan pēc mēģinājuma to sarežģīt un pārtaisīt pašu php tam neatbilstošā līmenī - kaut ko uz stingra OOP pusi kā Java, C# utml. Protams, tas ir SVIESTS! Php ir vienkārša skriptu valoda personīgajām mājaslapiņām, tāpēc nedomāju, ka tur vispār nepieciešams bāzt virsū kaut kādus mistiskus "frameworkus" jo php ir "frameworks" pats par sevi - ierobežotu iespēju valoda ar iebūvētām funkcijām un bibliotēkām. Var vienkārši ieviest vienotus MVC arhitekturālus patternus, bet nafig sarežģīt interpretējamu skriptu valodu, mēģinot uzlēkt augstāk par tās iespējām! Pirmkārt, php nemaz nav īsts tīrs OOP un nevar būt, tāpēc to ir absurdi izmantot kā tīru OOP valodu.

Link to comment
Share on other sites

Nu jau, nu jau - ne jau ar php veido tikai "mazas personīgās mājaslapiņas". (nez kādēļ to vienmēr saka JAVA programmētāji)

 

Freimworks paātrina izstrādes gaitu, konkrēti nosaka kur, kam ir jābūt, atvieglo programmētāju no daudz, viendabīgā, koda rakstīšanas. Par katra konkrētā freimwork'a izmantojamību jau ir cits stāsts.

 

Domāju, ka daudzi freimwork'i ir iespaidojušies no citu valodu analogiem (Django, Rails) un mēģina attēlot to darbību. Ne vienmēr tas ir viegli izdarāms, vai vispār iespējams, bet kādēļ necensties.

Edited by rATRIJS
Link to comment
Share on other sites

Freimworks paātrina izstrādes gaitu, konkrēti nosaka kur, kam ir jābūt, atvieglo programmētāju no daudz, viendabīgā, koda rakstīšanas. Par katra konkrētā freimwork'a izmantojamību jau ir cits stāsts.

Nē, "framework" nozīmē "ietvars". Reāli tas neatbild par izstrādes ātrumu vai gaitu. Tas neatbild arī par koda rakstības stilu, tas ir atkarīgs individuāli no programmētāja, tas var dot tikai ieteikumus. Koda rakstības stils paliek "valodas līmenī" un programmētāja paša "rakstības stila" līmenī, bet "freimvorks" par to tev neatbildēs. Jā, tas, ka frameworks var uzspiezt savu arhitektūru, tā ir patiesība un tas daļēji varētu būt arī freimvorka mērķis - pieprasīt, lai programmētājs veido programmu vēlamajā arhitektūrā, bet galvenokārt - tas piedāvā bibliotēkas, lai atvieglotu darbu pie vairāku veidu aplikāciju veidošanas - lai nav šīs lietas jātaisa pašam.

Bet ir tāda veca patiesība - "kas der visam, neder nekam". Katrai valodai un frameworkam ir savs uzdevums.

Bet ir vēl viena svarīga patiesība - universālai lietai jābūt vai nu perfektai vai tuvu perfektai. Un nevar censties uztaisīt "pilnīgāku, universālāku, advancētāku" (sauciet kā gribat) uz bāzes, kas nav tik "pilnīga, stabila, universāla, perfekta". Īsāk sakot, tas nozīmē, ka nav jēgas taisīt frameworkus, kas mēģina pildīt uzdevumus, kas sniedzas pāri php iespēju robežām, ja par "iespēju robežām" uzskatām "stabilas, viendabīgas un veiktspējīgas darbības kopu". Cerams, domu sapratāt.

 

Domāju, ka daudzi freimwork'i ir iespaidojušies no citu valodu analogiem (Django, Rails) un mēģina attēlot to darbību. Ne vienmēr tas ir viegli izdarāms, vai vispār iespējams, bet kādēļ necensties.

Kad cenšās, var arī pārcensties un beigās sanākt "bugi" un nopietnas nepilnības, kas liek rakstīt tā saucamos "hakus"! Vienam projektam šīs problēmas vēl var menedžēt, apkalpot un novērst, bet diezvai tūkstošu projektu bāzei, ja nevēlas vērā ņemamas "papildus izmaksas" gan laikā, gan naudā, gan nervos.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...