Jump to content
php.lv forumi

kurš ir labākais CMS


labaiss

Recommended Posts

  • Replies 39
  • Created
  • Last Reply

Top Posters In This Topic

Daudzus gadus iepriekš uzgāju PhpWcms. Vācu puiši to stutē.

 

Bet vai tas ir labākais? :) Par tādu pirmo reizi dzirdu.

Link to comment
Share on other sites

  • 1 month later...

Wintermute, Es patiešām gribētu redzēt kur Tu redzi to "vājprātu"? Cik pats redzu (un dzirdu) - Fuel's ir patiešām labi izveidots - ņemot vērā to, ka tas ir tikai RC1 stadijā.

Vai varbūt Tev ir iebildumi kā tādi pret MVC arhitektūru (HMVC?) vai objektu-orientēto programmēšanu, PHP kā tādu??

Link to comment
Share on other sites

Wintermute, Es patiešām gribētu redzēt kur Tu redzi to "vājprātu"? Cik pats redzu (un dzirdu) - Fuel's ir patiešām labi izveidots - ņemot vērā to, ka tas ir tikai RC1 stadijā.

Vai varbūt Tev ir iebildumi kā tādi pret MVC arhitektūru (HMVC?) vai objektu-orientēto programmēšanu, PHP kā tādu??

 

Man nav iebildumu ne pret OOP, ne pret (H)MVC , ne arī pret PHP.

Bet man ir iebildumi pret sliktu OOP, parodijām par MVC

(bet tas attiecas uz gandīz visiem php framework'iem .. neskaitās) un bardaku PHP kodā.

Es tikai nezinu no kura gala, lai te ķerās klāt .. referātu negribas rakstīt.

 

 

Ok , tā .. slikts OOP.

 

-------------------------------------------

 

Viena no vispārzināmām OOP praksēm ir šāda: katra metode 'zin' tikai par tiem objektiem,

kuri šai metodei ir tikuši padoti vai jau pieder metodi saturošajam objektam( wiki links ).

 

Piemērs kas ir pretrunā ar šo praksi:

$foo = new Bar();
$x = new Thing();
echo $foo->get_n(); // izvada 1
echo $foo->get_n(); // izvada 1
$x->do_something();
echo $foo->get_n(); // izvada 9

Šinī gadījumā , metodes do_something() izpildīšana objektā $x izraisīja izmaiņas objektā $foo,

lai gan tie nav nekādā redzamā veidā saistīti.

 

Šādu uzveidību parasti rada globali mainīgie,

vai cita veida globals stāvoklis ( singletoni , reģistri un citas struktūras kas izmanto statiskus mainīgos/funkcijas ).

 

Un diemzēl Fuel prakstiski visas Core klases satur vienīgi statiskas metodes un mainīgos.

Ja tu raksti klasi , kurā ir tikai statiskas metodes , tad tas nav OOP, bet gan procedurāls kods, kas 'ietīts' iekš namespace'ā.

 

P.S. lielākajā daļā "tīro" OOP valodu ( Scala, Smalltalk, etc. ) nemaz nav tāda keyword'a static.

 

-------------------------------------------

 

 

Nākamā problēma : cieša koda sasaistīšana.

 

Viena no labākajām OOP fīčām ir polimorfisms ( polymorphism ), kurš protams Fuel frameworkā netiek izmantots.

Rezultātā neeksistē veids kā realizēt veikt atkarību iekļaušanu ( Dependency Injection ), un tā vietā izstrādātāji oficiāli iesaka

"vienkārši nosauc klasi tāpat kā mēs to saucam un ielādē no citas lokācijas".

 

Un tad vēl protams ir ORM. Kas ticis veidots pēc ActiveRecord pattern'a.

Triks ar šo patternu ir tāds, ka Domeina Modelis tiek neatraujami sasaistīts ar datubāzes struktūru un veic "maģiskas" darbības.

Rezultātā, ja tiek, piemēram, mainīts nosaukums kolonai tabulā, tad ir jāmaina arī Modelis un visas klases, kas ar to saistītas.

Lielākā aplikācija rodas tāds kā lavīnas effekts.

 

 

 

-------------------------------------------

 

Ehh .. apnika.

 

Nedaudz par MVC. ( )

Tātad, ko dara katra komponente:

  • Model - domeina modelis. Atbild par aplikācijas biznesa loģiku. Modelis nav ORM un (ideālā gadījumā) pat nezin,
    ka tā ir datubāze no kuras nāk dati, un kurā tie tiek saglabāti;
  • View - skats. Atbild par lapas attēlošanas loģiku, templeitu renderēšanu un pieprasa informāciju no modeļiem
    (skats nemaina modeļu stāvokli, informācija parvietojas tikai vienā virzienā - no modeļa );
  • Controller - kontrolieris. Piesaista izvēlētos modeļus skatam un veic izmaiņas modeļu un skata stavoklī.
    (informācija pārvietojas tikai vienā virzienā - no kontroliera uz skatu un modeļiem )

 

Protams ka Fuel tā nav.

View ir pliks templeits, Controlieris satur presentācijas loģiku un

Modelis ir burtiski saaudzēts ar datubāzi.

 

Un tad vēl ir tā dīvainā situācija, kad Request klase kontrolē Controller instance .. ok , tas ir vienkārsi dīvaini.

 

 

-------------------------------------------

 

Un kas attiecas uz bardaku , tad neizplūdīšu sīkumos.

 


  •  
  • Metodei ir jāpilda viena un tikai viena funkcija.
  • Ja metodei viens no parametriem ir boolean, tad tur drošvien bija jābūt divām metodēm nevis vienai.
  • Ja metodes parametros ir divi boolean'i, tad programētājs no rīta nav savus 'vitamīnus' iedzēris.
  • Ja metodes nosaukums sākas ar "is_", tad tā atgriež boolean'u , nevis dažreiz atgriež booleanu un dažreiz atgriež objektu.
  • Ja metodes nosaukums sākas ar "set_", tad tā neko neatgriež. Utt., utjp..
  • Ja tu lieto frameworka core klasēs @ priekš kļūdu apspiežanas , tad tev vajag pa kaklu.

 

 

Apnika.

Drukas kļūdas nelabošu.

Link to comment
Share on other sites

Nu jā, taisnība jau ir.

 

Bet vai tad tas nav ne tikai ar Fuel'u, bet arī ar citiem tamlīdzīgiem "framework'iem"? CodeIgniter, Kohana, CakePHP... pat Zend?! Ir. Varbūt Viņi neseko striktam MVC arhitektūras piemēram... bet "kamoon", tas ir PHP, nevis kaut kāds C++ vai Java. Rezultāts ir apmierinošs. Jebkurā gadījumā... ko tu iesaki? Rakstīt visu no nulles? Nē? Lūdzu priekšlikumus ideālam "framework'am".

 

P.S. Necenšos Tevi apstrīdēt (redzami esi gudrāks par Mani)... vienkārši, pats gribu zināt.

Link to comment
Share on other sites

Sarakstīt jau nu daudz trololo, bet nu labi, pakomentēšu...

 

Viena no vispārzināmām OOP praksēm ir šāda: katra metode 'zin' tikai par tiem objektiem,

kuri šai metodei ir tikuši padoti vai jau pieder metodi saturošajam objektam( wiki links ).

Protams, ja tu nodarbojies ar dzenbudismu un tiecies uz kaut kādu iedomātu pilnību, tad jā.

Praksē, tu obketiem nepadosi norādes uz tādiem objektiem, kā db objekts, kešošanas objekts, utt. Savādāk tev liela koda daļa pārvērtīsies par objektu inicializāciju ar kaudzi objektu padošanu. Praksē tomēr tiks izmantots kāda globāla saikne uz Factory, Singletona paterniem un pietam kopā ar autoload funkcionalitāti.

 

Piemērs kas ir pretrunā ar šo praksi:

$foo = new Bar();
$x = new Thing();
echo $foo->get_n(); // izvada 1
echo $foo->get_n(); // izvada 1
$x->do_something();
echo $foo->get_n(); // izvada 9

Šinī gadījumā , metodes do_something() izpildīšana objektā $x izraisīja izmaiņas objektā $foo,

lai gan tie nav nekādā redzamā veidā saistīti.

Piemērs, kur tu šo praksi nevari apiet.

Datubāze. Tev ir divi objekti, kuri darbojas ar db. Nu netaisīsi tu katram savu konekciju tā viena iemesla dēļ, ka tad tu nevarēsi nodrošināt transakcijas.

 

Un tad vēl protams ir ORM. Kas ticis veidots pēc ActiveRecord pattern'a.

Triks ar šo patternu ir tāds, ka Domeina Modelis tiek neatraujami sasaistīts ar datubāzes struktūru un veic "maģiskas" darbības.

Rezultātā, ja tiek, piemēram, mainīts nosaukums kolonai tabulā, tad ir jāmaina arī Modelis un visas klases, kas ar to saistītas.

Lielākā aplikācija rodas tāds kā lavīnas effekts.

Ja tiek mainīt nosaukums kolonai, tad arī aplikācijā ar plikiem SQL, tev būs jāmaina visi SQL, kur izmanto šo kollonu. Tāda ir dzīve.

Bez tam izmantojot ORM, kuros kollonas definē modeļa definīcijā, db tabulas pa tiešu vispār neaiztiek, tā vietā to dara tūļi, kuri modeļa definīciju pārnes uz db.

 

 

Nedaudz par MVC. ( )

Tātad, ko dara katra komponente:

  • Model - domeina modelis. Atbild par aplikācijas biznesa loģiku. Modelis nav ORM un (ideālā gadījumā) pat nezin,
    ka tā ir datubāze no kuras nāk dati, un kurā tie tiek saglabāti;
  • View - skats. Atbild par lapas attēlošanas loģiku, templeitu renderēšanu un pieprasa informāciju no modeļiem
    (skats nemaina modeļu stāvokli, informācija parvietojas tikai vienā virzienā - no modeļa );
  • Controller - kontrolieris. Piesaista izvēlētos modeļus skatam un veic izmaiņas modeļu un skata stavoklī.
    (informācija pārvietojas tikai vienā virzienā - no kontroliera uz skatu un modeļiem )

Par vienvirziena datu plūsmu, no modeļa, tikai uz view-u un no kontrolera tikai uz modeli.

Praksē tas nav iespējams, jo kontrolerim gandrīz vienmēr būs nepieciešami dati no modeļa, lai veiktu tālākās darbības.

Piemēram, tu nospied pogu pirkt. Kontrolerim ir jāpārbauda vai lietotājam pietiek nauda (no user modeļa), jāpārbauda vai noliktavā ir prece (no storage modeļa), utt. un tikai tad, kad ir saņemti dati no vairākiem mopdeļiem, kontroleris var tālāk izlemt kādas darbības un izmaiņas veikt citos kontroleros un kādu view izsaukt.

 

Man praksē ir pierādījies, ka vispraktiskākais datu plūsmas veids ir, no kotroler uz modeli, no modeļa uz kontroleri un no kontrolera uz view-u.

 

 

 

[*]Metodei ir jāpilda viena un tikai viena funkcija.

Kas tas par murgu? Jebkuru darbu var sadalīt smalkāk - jebkuru funkcionalitāti var sadalīt smalkāk.

Tāpēc tāds jēdziens kā viena funkcija ir absurds.

Metodei jāpilda tāda funkcionalitēte, kuru loģiskā veidā var atdalīt no pārējā un katrs gadījums ir individuāls.

Pietam, viena metode var saturēt algoritmu, kurš izmanto vairākas citas metodes - bez tā nav iespējams iztikt.

Pēc tavas šīs filozofijas, nav nemaz iespējams būvēt normālus aplikācijas abstrakcijas slāņus.

 

[*]Ja metodei viens no parametriem ir boolean, tad tur drošvien bija jābūt divām metodēm nevis vienai.

Un ko darīsi, ja būs int parametrs ar iespējamām 5 vērtībām? Taisīsi 5 funkcijas.

Pietiek murgot. Sāc domāt.

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...