Jump to content
php.lv forumi

Mans pirmais mēģinājums iShop'am


Recommended Posts

Labdien!

 

Jau vairāk kā gadu apgūstu Kohana Framework. Sakarā ar to, ka nav pieredzes un dažreiz trūkst kādu zināšanu, taisīt ko tādu, ko līdz šim neesmu taisījis, aizņem ļoti daudz laika. Šis jau ir mans otrais darbs ar Kohana Framework. Pirmais bija blogs un ziņu portāls (to visu atradīsiet manā GitHub profilā). Un ja godīgi, tad es pirmo reizi vispār taisīju internetveikalu.

 

iShop'a oficiālais repo manā GitHub profilā.

 

Ar laiku tiks veikti labojumi. Gaidu Jūsu atsauksmes, ieteikumus, kritiku.

Link to comment
Share on other sites

Kāpēc tu nelieto ORM?

Tad tu skatos varētu izvairīties no atkārtošanās, piemēram - <?=Num::format(($product->price/100)/0.70,2)?> Tā vietā varētu vienkārši lieto kaut kādut $product->price_in_eur un aprēķināšanu jau veikt pašā modelī. Jo kas notiks tavā gadījumā, ja tev to koeficientu vajadzēs pamainīt? Iesi 100 vietām cauri un labosi?

Link to comment
Share on other sites

> **viena un tā paša produkta cenai jāparādās lapā, teiksim, miljons reižu**

 

Tad kas būs tāds gadījums, tad arī domāšu risinājumu.

 

Piemēram:

 

`$formatted_currency_for_single_item = Currency::pretty_format($item['title']); # That client is insane!`

Link to comment
Share on other sites

Un ja būs vairākas cenas, kas jāaprēķina, cena ar atlaidi, cena * skaits, cena ar atlaidi * skaits, un vēl viss kaut kas. Tev tur skatos jau parādisies daudz jaunu definētu mainīgo, ja tas pats produkts jāpadod uz kādu papildus skatu, jau esošajā skatā, kurā vēl būs jāpadod uz 7 zemākiem skatiem, kas ietverti viens otrā :), tad arī jāpadod līdzi produktam visas jau aprēķinātās cenas, lai nebūtu jārēķin aatkārtoti. Ja tas kādam citam ir jālabo/jāizmaina, tad viņam ir jāuzmin/jāmeklē, kurā skatā tev tie mainīgie tiek izveidoti. To protams, visu var aprēķināt kontrolierī, bet ja tie ir vairāki produkti, iesi divreiz vienam un tam pašam ciklam cauri? :) Orm gadījumā tu padod tikai produktu/s un par pārējo īpaši neuztraucies, ja kaut ko vajag jaunu - uztaisi metodes, kas to atgriež un lieto.

Kas notiks, ja pēkšņi kādu no tām cenām vairs nevajag, izdzēsīsi aprēķināšanu, jāiet visām vietām cauri, kur tas tiek padots citiem skatiem, jādzēš vēl tur. Orm gadijumā izdzēs tikai tās vietas, kur attiecigā cena tiek izdrukāta, vai slinkākajā gadījumā, uzliec lai attiecīgā cena vienmēr atgriež null.

Link to comment
Share on other sites

Saņemies, nu tam nevajag ORM!

 

Tu uztaisi metodi iekš modeļa, kurai padod vajadzīgās vērtības aprēķinu veikšanai. Šo **vienu metodi** tu izsauc iekš kontrolera. Metode atgriež masīvu ar veiktajiem aprēķiniem. **Vienu masīvu** ar aprēķiniem tu padod skatā. Kur problēma?

Link to comment
Share on other sites

Tas strādās, ja vajag vienam produktam aprēķināt cenu, bet ja tev ir produktu masīvs, tev jātaisa cikls, lai visiem aprēķinātu kontrolierī, un skatā tu atkal iesi tam pašam masīvam vēlreiz cauri, lai visu atkal attēlotu. :)

 

briedi, tāds, ka no objekta reprezentēt nepieciešamos datus ir vienkāršāk un ērtāk?

Link to comment
Share on other sites

> lai visiem aprēķinātu kontrolierī

 

Pirmkārt, tam ciklam ir jābūt modelī... tā ir biznesa loģika.

 

> un skatā tu atkal iesi tam pašam masīvam vēlreiz cauri, lai visu atkal attēlotu.

 

Tas cikls neko nemaina. Tu zini cik tam ORM ir apakšā desmiti ciklu?

 

P.S. **Es neesmu pret ORM.** Django ORM ir ļoti labs. Bet! Es vienkārši cenšos pateikt, ka ORM šeit nav obligāti jāizmanto un tas nemaz nav vienīgais veids, ka panākt vajadzīgo efektu. :)

Link to comment
Share on other sites

Nu ORM viņam "tiek izmantots", jo db ieraksti taču tiek nomapoti uz objektiem, tikai tiem objektiem vairs nav pilnīgi nekādas saistības ar attiecīgajiem modeļiem, jēga tad no tādiem modeļiem? Varbūt tad uztaisīt vienu helperi, kas nolasa nepieciešamos datus no datubāzes un nomapo uz objektiem.

 

Bet es tikai centos ieteikt, agri vai vēlu nonāksi pie secinājuma, ka ar šāda veida modeļiem sāksies visādas problēmas, tāpat biežāk nāksies atkārtoti rakstīt vienu un to pašu kodu, kā arī grutāka uzturēšana.

 

Kaut vai paskatoties, ko apraksta biznesa loģika, aka modeļi, tad

Business logic

  • models real life business objects (such as accounts, loan, itineraries, and inventories) - šis viņam ir fail
  • prescribes how business objects interact with one another - nosacīti ir, pētot visas metodes gan jau varēs saprast, kādas viņam saistības ar citiem modeļiem, tā teikt, ļoti pārskatāmi..
  • enforces the routes and the methods by which business objects are accessed and updated - vienīgais, kas ir

Link to comment
Share on other sites

Labdien!

 

Jau vairāk kā gadu apgūstu Kohana Framework. Sakarā ar to, ka nav pieredzes un dažreiz trūkst kādu zināšanu, taisīt ko tādu, ko līdz šim neesmu taisījis, aizņem ļoti daudz laika. Šis jau ir mans otrais darbs ar Kohana Framework. Pirmais bija blogs un ziņu portāls (to visu atradīsiet manā GitHub profilā). Un ja godīgi, tad es pirmo reizi vispār taisīju internetveikalu.

 

iShop'a oficiālais repo manā GitHub profilā.

 

Ar laiku tiks veikti labojumi. Gaidu Jūsu atsauksmes, ieteikumus, kritiku.

 

 

https://github.com/reGative/My-iShop/blob/master/application/views/acp/main.php#L11 - WTF??????????

https://github.com/reGative/My-iShop/blob/master/application/views/acp/products/info.php#L15 - WTF^2

https://github.com/reGative/My-iShop/blob/master/application/classes/controller/login.php#L16 - WTF^3

https://github.com/reGative/My-iShop/blob/master/application/classes/model/client.php#L114 - WTF^4, sanāk, ka ir iespējams ielogoties kā jebkuram lietotājam

https://github.com/reGative/My-iShop/blob/master/application/classes/controller/acp/products.php#L29 -> http://kohanaframework.org/3.2/guide/kohana/security/validation

https://github.com/reGative/My-iShop/blob/master/application/classes/controller/acp/products.php#L101 - droši, droši izmantojam transaction script'us ar 100 parametriem, kuru kārtību pēc nedēļas neviens vairs jau neatceras

https://github.com/reGative/My-iShop/blob/master/application/classes/controller/profile.php#L10 => https://github.com/reGative/My-iShop/blob/master/application/classes/model/client.php#L33 un https://github.com/reGative/My-iShop/blob/master/application/classes/model/client.php#L49 - jā šitā protams sanāk ātrāk(sarakstisks smaidiņš šiten)

https://github.com/reGative/My-iShop/blob/master/application/classes/controller/register.php#L22 - kāda jēga salīdzināt hash'us vai tie sakrīt, ja var vērtības salīdzināt un pēc tam nohashot pie saglabāšanas?

https://github.com/reGative/My-iShop/blob/master/application/views/home/main.php#L29 - inline CSS

https://github.com/reGative/My-iShop/blob/master/application/views/home/main.php#L10 - XSS

 

etc.

Link to comment
Share on other sites

Kāpēc tu nelieto ORM?

Tad tu skatos varētu izvairīties no atkārtošanās, piemēram - <?=Num::format(($product->price/100)/0.70,2)?> Tā vietā varētu vienkārši lieto kaut kādut $product->price_in_eur un aprēķināšanu jau veikt pašā modelī. Jo kas notiks tavā gadījumā, ja tev to koeficientu vajadzēs pamainīt? Iesi 100 vietām cauri un labosi?

 

Doma ir korekta.

 

> lai visiem aprēķinātu kontrolierī

 

Pirmkārt, tam ciklam ir jābūt modelī... tā ir biznesa loģika.

 

> un skatā tu atkal iesi tam pašam masīvam vēlreiz cauri, lai visu atkal attēlotu.

 

Tas cikls neko nemaina. Tu zini cik tam ORM ir apakšā desmiti ciklu?

 

P.S. **Es neesmu pret ORM.** Django ORM ir ļoti labs. Bet! Es vienkārši cenšos pateikt, ka ORM šeit nav obligāti jāizmanto un tas nemaz nav vienīgais veids, ka panākt vajadzīgo efektu. :)

 

Daļēja taisnība - aprēķinus nekad nevajag veikt kontrolierī. Taču tīri tehniski, kā jaut teicu, tā nav arī ORM funkcija. Šeit vairāk jautājums par to, vai iepriekšaprēķinu veikt visiem objektiem, vai katram objektam pēc pieprasījuma. Taču, tas atkarīgs no datu slāņiem - piemēram, kešošanas mehānismiem un vispārējas datu struktūras uzbūves. Varbūt šajā gadījumā problēmu vajadzētu risināt jau datu bāzes līmenī?

 

Taču tu kļūdies tajā, ka ORM te nav obligāti jāizmanto. Patiesībā, šī ir aplikācija, kurā ORM būtu jāizmanto par katru cenu. ORM pašā pamatā ir CRUD bez tiešas interakcijas ar datu bāzi izstrādes līmenī. Klasisks izstrādes laika un performances "tradeoff" - mēs iemainam +X ciklus kaut kur scenārijā pret -X% izstrādes laika. Fair enough for me.

 

(P.Š)atap. - Django orms ir vismurgainākais pasākums, kuru jēlkad radījusi cilvēce. Tiklīdz funkcionalitāte iziet kaut mazliet ārpus klasiska 2 relāciju CRUD, sākas nagu laužšana. Pameklējies, piemēru internetos netrūkst. Un ja vēl neesi ar to saskāries - apsveicu, esi laimīgs cilvēks. Pagaidām.

 

 

Par pašu šopu runājot, izskatās, ka faierfoksītis šito ir pasūtījis kādam indietim. Un pēc tam pārstaigājis ar cirvi pāri, "pielabojot" to, kas strādā. Get out. Now.

Edited by F3llony
Link to comment
Share on other sites

  • 3 months later...

Un ja viena un tā paša produkta cenai jāparādās lapā, teiksim, miljons reižu, tu katru reizi to pārrēķināsi?

Ja es uzietu veikalu kuraa viena un taa pati cena parādas 1'000'000 reižu, es no viņas noteikti tik pat ātri tītos prom. Nevaru iedomāties, kā tuvāko gadu laikā var normāli izskatīties veikals ar miljons precēm vienā lapā.

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