aplamas idejas?

[codez]

Ļoti interesē, kā, piemēram, "Do not repeat yourself" un "Loose coupling" netiek ievērots Zend Frameworkā.

ZF ir lēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēns.

Bez tā, kaut vai pāris lietas:

1) Kā zend tiek galā ar dažādu subdomeinu sūtīšanu uz vienu kontrolieri? Izmantot katram route veidam pa vienai routing objekta instancei? Tas ir lēēēēēēēēēēni. Vai ZF māk routing tabulu sakārtot tā, lai biežāk izmantotie ceļi tiktu testēti pirmie?

2) Kā zend tiek galā ar dažādu koda versiju palaišanu atkarībā no lietotāja. Teiksim, ir 100 000 lietotāji, bet vajag vienas jaunās fīčas testēt tikai uz 1000 lietotājiem, otras uz citiem 1000 , bet pārējiem vecās. Un tas viss, lai tiktu ievērot DRY un Loose coupling principi. Bez cores pārbūves neiztikt?!

3) Kā zend modeļi māk izmantot automātisku kešosanu memcached, lai katru reizi pie grieršanās pie datiem nebūtu jāraksta un varētu ievērot DRY:

if (!ielādēt_no_memkeša()){

 ielādēt_no_db();
 saglabāt_memkešā();
}

 

 

 

Kāda starpība, ja pats ietvars strikti ievēro DRY un Loose coupling'u, bet pats programmētājs raksta sūdīgu kodu?

Protams, tad nav starpība, bet, ja nu pats programmētājs ievēro šos principus, bet FW puse jāpārbūvē, lai tos varētu pilnībā ievērot? Tad labāk ir izveidot pilnībā no jaunu, kurš atbilst visām aplikācijas specifiskajām prasībām.

Es nesaku, ka katram tagad ir jābūvē savs MVC ietvars (ne katrs to var jēdzīgi izdarīt), bet apgalvojums, ka vienīgais labums pašam būvēt, ir tikai mācīšanās, ir absurds, jo ir gadījumi, kad risinājums būvēt savu MVC kodolu ir daudz efektīvāks, kā izmantot esošos nepilnīgos risinājumus.

 

 

Manuprāt nav nozīmes ietvaram, galvenais, lai pašam ērti strādāt. Tas, cik kvalitatīvs kods beigās būs, ir taču atkarīgs no paša programmētāja.

Tikai vienā gadījumā tu mērķi sasniegsi 2x ātrāk un lapa tērēs 5x mazāk servera resursu.

[Mr.Key]

ZF ir lēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēēns.

Bez tā, kaut vai pāris lietas:

1) Kā zend tiek galā ar dažādu subdomeinu sūtīšanu uz vienu kontrolieri? Izmantot katram route veidam pa vienai routing objekta instancei? Tas ir lēēēēēēēēēēni. Vai ZF māk routing tabulu sakārtot tā, lai biežāk izmantotie ceļi tiktu testēti pirmie?

2) Kā zend tiek galā ar dažādu koda versiju palaišanu atkarībā no lietotāja. Teiksim, ir 100 000 lietotāji, bet vajag vienas jaunās fīčas testēt tikai uz 1000 lietotājiem, otras uz citiem 1000 , bet pārējiem vecās. Un tas viss, lai tiktu ievērot DRY un Loose coupling principi. Bez cores pārbūves neiztikt?!

3) Kā zend modeļi māk izmantot automātisku kešosanu memcached, lai katru reizi pie grieršanās pie datiem nebūtu jāraksta un varētu ievērot DRY:

1) Tu vari izveidot savu router objektu. Vismaz es tā darītu palielos projektos. Bet ja pareizi saprotu, tu domā subdomeinus katram lietotājam. Zend_Controller_Router_Route_Hostname ļauj tev definēt mainīgo daļu, kas uz kontrolieri tiks padota kā mainīgais. Routes tiek procesētas apgriezti to pievienošanas (definēšanas) secībā. Tātad, var izmantot pievienošanas secību.

Ir viens Router objekts un Routes. Jā, katra no Routes rezultējas objektā. Galu galā runa ir par PHP5 un OO. Bet, kā jau minēju, var uzrakstīt savu Router klasi un izmantot to standarta Routera vietā.

2) Tas galīgi ietvara uzdevums, tas ir tavas aplikācijas uzdevums. Bet ZF gadījumā FC plugins vai pielāgots Dispatcher. Piemēram, ja lietotājs atbilst noteiktam parametram, kontrolliera Something vietā izsauc SomethingNew. Pārējais viss paliek tāpat... dažas rindiņas FC plagina metodē (if ($user->kautkas) { $request->setControllerName($request->getControllerName() . 'New'); }). Protams, jaunās fīčas tev ir atsevišķā kontroliera failā. Vai arī action name SomeAction -> SomeActionNew .. utt. Vai arī padod parametru "Uberkruta" un savās metodēs to izmanto. Tas, ja neizmanto atsevišķas direktorijas vai pat serverus, lai nodalītu sources ar dažādiem tegiem. Šādā gadījumā visdrīzāk jāizmanto cita metode (subdomeini vai kookijs, kuru apstrādā loadbalanceris), bet arī šajos gadījumos ar plaginu bāzes versijā var novirzīt lietotājus uz jauno versiju un jaunajās versijās var pārbaudīt, vai lietotājam ir ļauts to izmantot.

Kāds tam sakars ar FW vispār?

3) Zendam nav modeļu. Modeļus raksta programmētājs. Iespējas, kā automatizēt memcached lietošanu ir atkarīgas no tā, kas tiem modeļiem jādara un kurā brīdī paredzēts lietot cache. Kas attiecas uz DB, nav nācies to padziļināti pētīt, bet man ir smagas aizdomas, ka to primāri realizē datubāzes servera pusē, nevis aplikācijā rakstot IFus. Aplikācijā veido aplikācijas izvada kešus, nevis pieprasījuma kešus.. kāda jēga tev kešot DB atbildi un ielikt to izvadē, ja var iekešot uzreiz visu izvadi? Un šim pēdējam gadījumam, jā, Zendam ir šim nolūkam lietojamas cache un memcache klases.

Arī nav skaidrs, kāds tam ir tiešais sakars ar FW...

 

Par ātrumu vai lēnumu. Tas ir atkarīgs no aplikācijas. Mazītiņai aplikācijai salīdzinoši servera resursu patēriņš būs liels, tā ir taisnība. Pie lielas slodzes arī var rasties zināmas problēmas. Bet ja runa ir par lielu uzņēmuma aplikāciju vai aplikāciju, kas nav draugiem lv vai cita milzīga sociālā portāla līmenī, tas ir ok. Par soc. tīkliem runājot, iespējams, tā pati Kohana būs vairāk piemērota. Anyway, tas nav iemesls, lai norakstītu kādu FW.. vienkārši jāizmanto cits divritenis (jau izgudrots).

 

Tikai vienā gadījumā tu mērķi sasniegsi 2x ātrāk un lapa tērēs 5x mazāk servera resursu.

Tas tāds lone code warrior variants.

Tagad iedomājies projektu ar 10 programmētājiem, katram dažāda pieredze, projekta termiņš 3 mēneši. Tavā gadījumā, gandrīz droši, ka pēc 3 mēnešiem puse programmētāju būs aizgājuši, vadošais programmētājs kaut ko murgos par savu FW, projekts izgāzies, jaunie programmētāji pirmās 2 nedēļas pavadīs lai vispār kaut ko saprastu... vēl 3 mēneši. Algas visiem mazas, jo produktivitātes nav.

 

Tā vietā var izmantot Zend, Symfony, CakePHP, CodeIgniter, Yii, Kohana vai citu TOP FW, kur freimworka daļa repozitorijā ir iečekota ar svn:externals, programmētāji pirmajā dienā var veidot savus modeļus, kam jāveido modeļi vai kontrollierus, utt. Juniori apgūst FW izmantojot grāmatas un internetu, nevis gaidot, kad vadošais programmeris atbrīvosies, lai izskaidrotu elementāru lietu. Utt. Projekta ātrdarbība tiek nodrošināta ar cache, cache un cache.

 

Protams, neviens FW neizglābs no debīlas projekta vadības.

Edited December 4, 2011 by Mr.Key

[codez]

1) Nu jā, bet, ja ir 50 iespējamie routing ceļi, tad tas nozīmē, ka tiks veidoti 50 routing objekti - tas ir lēēēni.

2)Nē, tas ir tieši MVC ietvara uzdevums. Bet lietas būtība ir nedaudz savādāka. Vienreiz nedēļā/divās/mēnesī tiek uzpdeitota live aplikācija, viss, kas pa nedēļu pabeigts, tiek laists dzīvajā. Pēc tam, kad uz webserveriem ir iesūtīta jaunā versija, kuras kontrolieri atroda vielaikus ar vecākām versijām, tiek iedarbināts jaunās versijas palaišanas mehānisms - sākumā paši notestē, tad palaiž uz nelielu skaitu lietotāju, pēc tam, ja kļūdas netiek detektētas, jaunā versija tiek palaista uz visiem. Kāpēc tas ir MVC ietvarā? Tāpēc, programmētājs neko nezin, par versijonēšanu, viņš updeito vecos kontrolerus ar saviem uzlabojumiem, bet serverī MVC nodrošina šo versiju pakāpenisku un kontrolētu pārēju. Pie tam automātiski atceļ updeitošanu, ja jaunā versija sāk mest ietvaram detektējamas kļūdas.

3)Es runāju par memcached serveri, ar ko mysql serverim nav nekāda tieša sakara, tāpēc šī loģika jārealizē ir PHP pusē. Protams aplikācijas modeļus raksta aplikācijai, bet modeļa ietvars ir MVC sastāvdaļa.

Savukārt DB atbildi ļoti bieži kešo pēc id, jo aplikācijas izvadē var būt desmitiem dažādu variantu, kur katrā tiek izmantotas vairākas db atbildes, pie tam viena db atbilde pēc id var būt vairākos aplikācijas izvados. Līdz ar to, jebkurā no izmaiņām db, mainās vesela kaudze aplikācijas izvažu, kamēr db izvade tikai viena. Reāli praksē ir pārbaudīts, ka daudz izdevīgāk ir kešot db slāni un pietiekami mainīgām aplikācijām aplikācijas izvades slāni pat neatmaksājas kešot.

Savukārt zend memcahed klase tikai strādā ar memcached serveri un tam tiešām nav nekāda sakara ar MVC, jo memcached klases ir daudz un džādas un nekādi cieši neintegrējas MVC ietvarā, kamēr modeļa ietvars, kurš sevī var ietvert modeļa atgriesto datu kešošanu ir MVC sastāvdaļa.

 

 

Vēlreiz, kas attiecas uz MVC, tad tas ir boot fails, kontrolera, routera, modeļa un viewa ietvars. Tas nav nekāds kosmoss, lai to uzrakstītu dienas vai divu laikā, kas attiecas uz visām pārējām klasēm: db, memcahced, bilžu apstrādes, utt. utjp. tad tām nav tieša sakara ar MVC un tās es arī bieži izmantoju jau gatavas.

[Mr.Key]

1) Tu vari izveidot savu router klasi, kas neizveido 50 objektus, bet darbojas tieši tā, kā vajag. Ir FW ar iespēju izveidot ātru savu routeri un tajā pašā laikā izmantot pārējās FW priekšrocības. FW piedāvā standarta routeri, specifiskiem gadījumiem izveido savu variantu un lieto!

2) Arī šādu variantu var realizēt, vienkārši attiecīgā loģika jārealizē FrontController pluginā vai pielāgotā Dispatcher objektā, vai objektu loaderī. Viss, kas vajadzīgs, ir lai tas zinātu, kā uz servera tiek uzglabāti veicie un jaunie faili. Nav FW uzdevums, tas ir aplikācijas uzdevums, kuru ērti var integrēt šajā FW.

3) Modeļa ietvars nav ZF sastāvdaļa. Tas ir visbiežākais pārpratums, ko slinki programmētāji sagaida no ZF. Tātad, ja ir paredzēts izmantot memcached, visdrīzāk, ka jāveido Modeļa bāzes klase, kuru extendojot, automatizē memcached pieprasījumus.

 

No visas lielās ZF bibliotēkas uz MVC attiecas Application, Controller, View (un Layout, un dažas citas). ZF ir gan MVC ietvars, gan plaša koda bibliotēka.

 

Ja tu MVC daļu vari uzrakstīt dienas vai divu dienu laikā, tad tas ir ok. Principā jebkurš seniors to var. Ja runa ir par nelielu īstermiņa uzdevumu, tad es tā arī darītu. Problēma ir tas, ka tu noniecini FW, neizprotot to darbību un to, kam tie ir paredzēti un kā tos pareizi jālieto. Dažiem FW viņu piedāvātais risinājums ir interesants tieši ar to, ka tas ir gatavs ilgtermiņa lietošanai (uzturēšanai) no pirmās dienas, kad laika gaitā tapušas situācijas ir vienkārši ieviest.

 

Piemēram, ja parādās vajadzība routes definēt adminā, tad savas niecīgās aplikācijas gadījumā tā var būt problēma. ZF gadījumā tā ir admin lapa, ar kuru apstrādā config failu, kuru padod routera objektam pie ielādes. Ja tas ir darīts jau sākumā, tad aplikācija vispār nav jāmaina, tikai jāpievieno iespēja rediģēt to config failu. Un daudzi citi gadījumi, kas tieši izpaužas kā nenormāli lielas DRY un loose coupling iespējas. Kaut vai tā pati jauno fīču testēšana.

 

Savukārt, ja tu raksti savu MVC, jo tas nepieciešams, lai realizētu tavas specifiskās īpatnības, tieši tas norāda uz to, ka tur NAV loose coupling (ja ir tā, kā pats saki, katram projektam raksti savu MVC) ...

Edited December 4, 2011 by Mr.Key

[rATRIJS]

Redzot Zend FW klases nosaukumu - Zend_Controller_Router_Route_Hostname (vai kaut kas tāds), man automātiski nekad negribās pieskarties Zend FW...

 

(null)

[daGrevis]

Redzot Zend FW klases nosaukumu - Zend_Controller_Router_Route_Hostname (vai kaut kas tāds), man automātiski nekad negribās pieskarties Zend FW...

 

(null)

 

Un ko tu iesaki? Nosaukt to vienkārši par 'Hostaname' un saksarties ar 'namespace problēmām'?

[rATRIJS]

Es rakstītu savu FW tikai tapēc lai nebūtu jāredz/jāraksta tādi klašu nosaukumi. Nebija viņiem diži daudz citu iespēju, piekrītu, bet man tas ir gana liels iemesls lai viņu nelietotu.

 

Un v5.3 atbalsta namespaces. Piekrītu gan ka pārrakstīt visu Zend nebūtu viegli...

 

(null)

[briedis]

Es rakstītu savu FW tikai tapēc lai nebūtu jāredz/jāraksta tādi klašu nosaukumi. Nebija viņiem diži daudz citu iespēju, piekrītu, bet man tas ir gana liels iemesls lai viņu nelietotu.

 

Un v5.3 atbalsta namespaces. Piekrītu gan ka pārrakstīt visu Zend nebūtu viegli...

 

(null)

 

Kohanā tak ir līdzīgi - viss atkarīgs, cik dziļi mapēs grūd to klasi. Tomēr ir bonuss - cascading file system

Edited December 4, 2011 by briedis

[Mr.Key]

Protams, ka tas ir grūti. To dara liela komanda. ZF2.

Jo vairāk jūs par saviem FW runājiet, jo vairāk man liekas, ka jūs nesaprotiet, par ko vispār jūs runājiet.

Piemēram, kur var ielādēt jūsu FW un kāda ir viņu lietotāja bāze? Ja lietotājs ir 1 jūsu aplikācija, tas nav FW. Tā ir jūsu aplikācija.

[daGrevis]

Un ko mainītu namespace izmantošana, ko?

 

No:

 

class Zend_Controller_Router_Route_Hostname {

 

...uz:

 

namespace Zend\Controller\Router\Route;


class Hostname {

[Mr.Key]

Jā, tikai to. Līdzīgi kā C#, Javā utt. Neesmu pārliecināts, bet šķiet, ka šo fīču lielā mērā ievieš dēļ pieprasījuma no tautas, kas ienāk PHP ar pieredzi citās valodās.

Patiesībā, nav nemaz tik slikti.

[rATRIJS]

Un ko mainītu namespace izmantošana, ko?

 

No:

 

class Zend_Controller_Router_Route_Hostname {

 

...uz:

 

namespace Zend\Controller\Router\Route;


class Hostname {

 

To arī mainītu jā. Garie nosaukumi (šajā gadījumā namespace'i) mētāsies tikai klases (faila) augšā. Pārējā kodā būs īsi nosaukumi. Manuprāt, milzīgs ieguvums...

 

Lai vai kā - tik daudz klases lielākajā vairumā projektu nav vajadzīgas. Tādēļ pašveidots FW būs jaukāks un tīrāks (vieglāk rakstāmas aplikācijas tādā). Tiesa ne vienmēr ir vērts izgudrot savu - atkarībā no aplikācijas ērtāk, lētāk un ātrāk var būt izmantot jau gatavu.

 

Mr.Key - šaubos vai daudzi pašrakstītie būs pieejami lejupielādei jo tie tiek izmantoti iekšienē (internally) un ir pārāk specifiski, lai piedāvāto to publikai. Manā kompānijā, kur strādāju ir divi fiziski atšķirīgi FW. Katrs tiek izmantots vismaz 4 dažādās aplikācijās.

[daGrevis]

To arī mainītu jā. Garie nosaukumi (šajā gadījumā namespace'i) mētāsies tikai klases (faila) augšā. Pārējā kodā būs īsi nosaukumi. Manuprāt, milzīgs ieguvums...

 

Ja? Cik bieži tev klasē būs jāizsauc kkas, kas ir zem, šajā gadījumā, Zend\Controller\Router\Route namespace'a? Drīzāk būs vai nu $this, vai nu, un tur jau tā lieta (!), Other\Namespace\Lorem\Ipsum. Tātad Other_Namespace_Lorem_Ipsum vietā būs Other\Namespace\Lorem\Ipsum. Jā, ieguvums ir 'milzīgs'! :)

[rATRIJS]

Ja? Cik bieži tev klasē būs jāizsauc kkas, kas ir zem, šajā gadījumā, Zend\Controller\Router\Route namespace'a? Drīzāk būs vai nu $this, vai nu, un tur jau tā lieta (!), Other\Namespace\Lorem\Ipsum. Tātad Other_Namespace_Lorem_Ipsum vietā būs Other\Namespace\Lorem\Ipsum. Jā, ieguvums ir 'milzīgs'! :)

 

Nē.

 

namespace whatever;

use Other\Namespace\Lorem\Ipsum;

class Test {
 public function test() {
   Ipsum::test();
   Ipsum::test2();
 }
}

 

Nezinu gan ko tā Zend namespace router klase dara, bet ļoti pieļauju, ka viņu vajag izmantot viarākkārtīgi un ērtāk būtu rakstīt vienkārši Hostname nevis to garo tārpu priekšā kas izskatās vienkārši pretīgi.

 

Kā piemērs - viena klase var izmest daudz, dažādus exceptionus. Būtu galīgi garām visu laiku rakstīt throw Stupidly_Deep_Path_Test1Exception; throw Stupidly_Deep_Path_Test2Exception; utt. Ar neispeisiem sākumā raksti use Stupidly\Deep\Path\Exceptions as E; un kodā throw E\Test1Exception; un throw E\Test2Exception;. Manuprāt KRIETNI labāk, ērtāk un lasāmāk.

[daGrevis]

Būs laikam jāpiekrīt, jā.