Kā aizievietot vairākus vienādus vārdus?

[Maris-S]

Problēma ir tāda ka es runāju par to, vai ir vajadzīgs pārrakstīt veselu klasi, kāda jau ir, bet Tu runā par to kāds Tev ir ietvars. :)

 

 

Pirmām kārtām, jā, exceptions pārtrauks skripta izpildi, tāpēc ar exception handleri būtu jātaisa tādas izvirtības kā redirektēšana uz kļūdu paziņojumu lapām utt., tieši tāpēc arī neslinkoju pierakstīt lieku rindiņu un izmantoju try - catch, ne tikai logu rakstīšanai, bet vispār, jo man exceptions izmantošana šķiet diezgan ērta.

 

 

Ja to Tavējo koda gabalu:

 

function getItems(){
  if ($uid=Auth::id()){
   	echo DB::q('SELECT * FROM users_items WHERE uid=%s',$uid)->getRows('json');
  }
}

 

pliku iemest failā un viņu izsauktu viņš vienkārši nestrādātu, jo vajadzīgs ietvars, kas ļaus visu inicializēt. Tad jautājums ir, kādi iemesli ir līdzīgas ietvara un inicializācijas pieejas realizēšanai priekš šāda koda:

 

try {
if ($user->is_logged_in())
   	echo(json_encode($user->get_items()));
} catch (Exception $e) {
$log->write("Couldn't get user date.", $e);
}

 

?

 

Ietvara sistēma tā pat varētu inicaializēt gan user, gan db mainīgo, bet, jā, ja neizmantotu singleton patternu, mainīgie būs jāinicializē vienmēr un ja lietotājs nebūs ielogojies, db mainīgais būs inicializēts vienalga, bet tas jau ir pavisam cits stāsts.

 

Tas piemērs ar try - catch ko es iepriekš parādīju pavisam nav domāts kā ietvara vai kādas incializācijas paraugs, tas ir vienkāršs piemērs datubāzu kļūdu logošanai ārpus klases. Pēc kādas pieejas tur tiek inicalizēti dažādi objekti šajā gadījumā ir pilnīgi vienalga. Priekš kam rādot vienkāršu try - catch piemēru man būtu vēl jāstāsta kā izveidot ietvaru? Tur to sākumu ar include un mainīgo inicializēšanu vispār varētu mest ārā un piemēra būtība saglabāsies, vienkārši izkopēju ar sākuma rindiņām. Vajag singleton patternu, lūdzu atbilstoši taisam ietvaru ar singleton patternu, kur problēma?

 

Respektīvi katra klase tiek ielādēta un inicializēta tajā brīdī, kas kontrolerī tiek pirmo reizi izmantota (šo jau es atkārtoju 5 reizi, bet šķiet, ka tu vēl nesaproti).

 

Es ļoti labi zinu kas ir singleton patterns un kā viņš strādā, arī saprotu kas un kā Tev inicializējās, vismaz virspusēji, bet kā jau teicu es nerunāju par ietvara sistēmas veidošanu, bet gan par to, ka gan logošana, gan citas, tieši nesaistītas, ar db lietas, ir iespējams izveidot arī ārpus db klases, kā arī par to ka singletton patterns ir iespējams arī ar PDO klasi, to nepārrakstot. Tādā veidā gan paša klasēm, gan PDO klasei tiek atstātas tieši darbības ar datubāzi, nevis logeri, datu struktūru atšifrētāji un līdzīgas lietas. To es jau teicu no paša sākuma. Par to kādu pieeju izmantot un ko tieši likt klasē jau ir jāizvēlas katram personīgi.

 

 

 

Tātad vēlreiz, visi mani piemēri ko es iepriekš esmu iedevis un apskatījis neapraksta nekādu kopēju ietvaru vai sistēmu, bet būtībā ir komentārs un atbilde uz šo:

 

Tad jautājums, kādi ir tavi apsvērumi, lai nebūvētu savu custom db klasi, neatkarīgi vai uz PDO, vai mysqli bāzes?

Plusi būtu: vari izveidot klāt Singleton vai citu paternu instan(ces/ču) iegūšanai, automātisku parametru eskeipošanu, dažādas papildus funkcijas dažādas formas datu atgriešanai, iebūvēt query log-u un kļūdu log-u.

 

Īsumā bez piemēriem atbildes būtu:

 

Singleton patternu var ziveidot bez lielas custom klases veidošanas, bet izveidojot tikai tieši to ko vajag singleton patternam.

Automātisko parametru eskeipošana man nemaz tā īsti nepatīk, kā jau minēju, zūd kontrole pār eskeipošanu.

Dažādas funkcijas, kas nav tieši saistītas ar datubāzes lietām es tomēr labāk apstrādātu atbilstošās klasēs.

 

Lūk tādi būtu īsumā apsvērumi kāpēc es nepārveidoju jau esošu db klasi. Īsi un konkrēti šoreiz laikam būs daudz labāk, jo parādot piemērus sākās domāšana kā viņus izmantot sazin kādās sistēmās par kurām nemaz neiet runa un par kurām es pat neaizdomājos rakstot jebkuru no piemēriem.

[codez]

Problēma ir tāda ka es runāju par to, vai ir vajadzīgs pārrakstīt veselu klasi, kāda jau ir, bet Tu runā par to kāds Tev ir ietvars. :)

Pārrakstīt nevajag, tas pat būtu diezgan sarežģīti pa tiešo ar fsock izdarāms.

Vajag papildināt esošo funkcionalitāti tā, lai ir ērtāk programmēt tālāk.

 

Pirmām kārtām, jā, exceptions pārtrauks skripta izpildi, tāpēc ar exception handleri būtu jātaisa tādas izvirtības kā redirektēšana uz kļūdu paziņojumu lapām utt., tieši tāpēc arī neslinkoju pierakstīt lieku rindiņu un izmantoju try - catch, ne tikai logu rakstīšanai, bet vispār, jo man exceptions izmantošana šķiet diezgan ērta.

Piekrītu, ka exceptioni ir laba lieta, bet, piemēram, es lietotājam paredzētos kļudas ziņojumus metu ar speciālu exception klasi un pārtveru nevis katrā ajax kontroliera action metodē, bet gan tur, kur šī metode tiek izsaukta un Response objektam pievienoju kļūdu.

Ajax kontroliera piemēros echo rādīju tikai vienkāršibas pēc, realitātē es izmantoju Response klasi, kura arī visu dara automātiski, tai skaitā izvadi. Un vietā kur tiek izsauktas ajax kontroliera action metodes, arī ir try un catch, kurš lietotājam parādāmu kļūdu gadījumā papildina response objektu ar lietotājam rādāmajām kļūdām. Fatālas kļūdas es pārķeru un logoju korē. Tādā veidā man katra kontroliera action metodē nav jāraksta try catch statementi.

 

 

Ietvara sistēma tā pat varētu inicaializēt gan user, gan db mainīgo, bet, jā, ja neizmantotu singleton patternu, mainīgie būs jāinicializē vienmēr un ja lietotājs nebūs ielogojies, db mainīgais būs inicializēts vienalga, bet tas jau ir pavisam cits stāsts.

Diemžēl šāda sistēma, piemēram, man nderētu, jo projektos vidēji ir ap 20 dažādām bibliotēkām, kuras ir jāinicializē vai citādi jāizmanto, populārākās no tām: db, kešs, logošana, autorizācia, vairāki filtri, 3-šās puses api, failu storedžs mākonī, u.c.

Tādā veidā, ja es visas inicializēšu aplikācija reāli bremzēs, ja neinicializēšu, tad nāksies inicializēt katrā kontroliera action metodē. Ne viens, ne otrs variants mani neapmierina.

 

 

Automātisko parametru eskeipošana man nemaz tā īsti nepatīk, kā jau minēju, zūd kontrole pār eskeipošanu.

Ietvaram arī tieši tas jānodrošina - "zūd kontrole pār eskeipošanu" - tātad jāeskeipo ir visi dati.

Vispār tieši jau tāpēc mēs esam programmētāji, lai pēc iespējas vairāk kontroli deleģētu skaitļotājiem.

 

 

P.S.

Bet vispār laba diskusija. Ļāva paskatīties uz savas koncepcijas vājajām un stiprajām vietām, kā arī radās pāris jaunas domas, kā lābāk darīt.

Edited August 12, 2011 by codez

[Maris-S]

Pārrakstīt nevajag, tas pat būtu diezgan sarežģīti pa tiešo ar fsock izdarāms.

Vajag papildināt esošo funkcionalitāti tā, lai ir ērtāk programmēt tālāk.

 

Nu es domāju ka ļoti labi saprati ka tieši funkcionalitātes paplašināšanu un pilnīgi jauna objekta uzrakstīšanu es arī domāju. :)

 

 

Diskusija ir vienmēr laba liet. Man vēl viens jautājums radās.

 

3-šās puses api

 

Kā Tu parasti viņus dabū uz singleton stilu? Piemēram, ja ne Tevis veidotā klase nav singleton stilā sarakstīta, Tu viņu pielabo, vai pārtaisi extendojot? Te man nu gan liekās ka dažreiz daudz vieglāk ir inicializēt to mainīgo atsevišķi, ja viņu bieži neizmanto, tikai vajadzīgajās vietās, piemēram pdf ģenerēšanas klase, ja viņu izmanto 2 vai 3 vietās pa visu lietojumu, vai nebūs vienkāršāk viņu vienkārši inicializēt?

[codez]

Nu es stingri ievēroju lazy loading un lazy evaluation principus, tāpēc neko neinicializēju bez vajadzības.

Par 3-puses api. Daudzi api sastāv no vairāk failiem un tie visdrīzāk neatbilst manai esošanai failu struktūrai un autoloadinga manidžēšanas funkcionalitātei. Tāpēc parasti uztaisu klasi, kura ir kā starpnieks un kuras mapē iekopēju 3-puses bibliotēku un inklūdošanu taisu starpniek klasē, jo mans autoload handleris nemācēs inklūdot sveša struktūrā taisītas bibliotēkas failus.

Visbiežāk šī klase ir pliks Factory vai Singletona paterns, citreiz pielieku visbiežāk lietoto funkcionalitāti.

Piemēram, HtmlPurifierim bija klasei metodes, kurās HtmlPurifieris tika inicializēts un konfigurēts divos variantos, kurus man aplikācijā vajadzēja.