Singleton pattern i static

  1. Da li ima smisla koristiti singleton pattern ili je van mode?

  2. Da li ima smisla koristiti static funkcije?

Radim svoj mvc, osnovni dio sam slozio, router, autoload, dohvat podataka, renderiranje view-a.

Medjutim nisam zadovoljan.

Imam jedan stari framework koji koristi static funkcije tj. sve funkcije su static, a osnovni dio frameworka se sastoji od 6 ili 7 klasa.

Pa sam mislio iskoristiti taj framework, a njega bi preradio. Slozio bolji router, klasu za db connection, db klasu i sl.

Kako koristim uglavnom codeigniter, trojku sam doktorirao, cetvorka je u dolasku, u alpha verziji je sve super bilo, beta verzija, ne radi im spremanje podataka kad se koriste entiteti, napominjem da je to u alpha verziji radilo, isti code, sve isto.

Pun k… mi je sto se iz verzije u verziju mijenjaju stvari. Zato radim svoj mvc.

Npr. solaris OS je primjer inzenjerstva, driver compiliran za verziju 3 pred 25 ili 30 godina radi i dan danas na novom solarisu.

Doduse ovo je primjer, inace solaris OS su umirovili i to su bili inzenjeri.

Isprobao sam jedno 30 frameworka i svaki ima mane. A to znaci, proucio detaljno dokumentaciju i nisu me nesto impresionirali.

Od svih njih jedino laravel, symfony, phalconph i codeigniter imaju dobru dokumentaciju i mozda cakephp, ali u vecini slucajeva nije potpuna tj. dokumentacija je sa osnovnim primjerima i sl.

Doduse sad ucim laravel i yii, ali …

Treba dodatni tutorial, knjiga, visiti po forumima da se saznaju informacije.

Da se razumijemo, nemam nists protiv ni jednog frameworka, jedini framework koji me zadovoljavao, bio je codeigniter 3.

Super framework, mali, imao je sve sto treba imati i oni odlucili sve promijeniti u verziji 4, umjesto da su poboljsali verziju 3.
I sad verzija 4 je najmanje duplo sporija.

Ja obično s singlthonom radim dohvaćanje trenutno logiranog usera, za to mi je ok.
Možeš još koristiti i kod konekcije na bazu.
Eventualno za logiranje nekih opcija, ali tu koristim chain of responsibillity ili aop.

  1. Singleton je anti-pattern jer se rjesava problem na fundametalno pogresan nacin i samim time dozvoljava postojanje “global statea” u aplikaciji.
    Ako zelis uvijek dobiti jednu te istu instancu necega u lifecycleu requesta, vidi service locator pattern.
    Ukratko, postoji jedan servis koji resolva sve servise koje trebas – aka Container.
    Ako imas servis “Foobar” i zelis da u lifecycleu jednog requesta moze postojati samo jedna instanca Foobara, kod registriranja Foobar servisa u container ces navesti da uvijek zelis dobiti istu instancu.
    Onda, kad god ce Container biti zatrazen “daj Foobar”, on zbog te definicije zna da mora uvijek vratiti istu instancu umjesto da kreira novu.
    Svaki popularni framework to ima rjeseno – npr vidi “Binding A Singleton” u Laravel docsima ili kako je to rjeseno u Symfonyu s takozvanim “shared” servisima.

  2. Kratki odgovor: ne. Dugi odgovor: neeeeeee :slight_smile:

1 Like

Uzmimo da vas klijent trazi web shop, a nema love za vps u startu ili ima za neki manji , ne zeli magento, wocomerce i sl., nego jednostavan webshop, da ima kosaricu, online placanje, pracenje racuna, narudzbi, minimalno.

Sto bi mu ponudili? Web shop koji? baziran na cemu?

Implementacija i prilagodba do 60 dana(3 mj), buđet do 25 k kn, od toga na dizajn ide 8-12 k kn.

Sto cete izmisliti?:innocent:

To je ovaj framework koji sam spominjao,a
koristi static funkcije, ne razvija se vise. Code je stari, zadnja verzija izdana 2012 ili 2013 god.

Ja bih mu svejedno savjetovao da instalira WP plus WooCommerce.

Ne znam zasto stalno spominjes VPS, sta to ima veze sa bilo cim. Dok sam radio u agenciji smo na shared hostingu imali po 10 - 20 Shopova sto Shopware, sto WooCommerce.

2 Likeova

I kako to radi u praksi?

Kako bi radilo, radi najnormalnije. Postavi se caching i shopovi su se ovisno od templatea do templatea ucitavil svi ispod 2 sekunde, bilo je njih i koji su isli i ispod sekunde. Prosijek broja proizvoda po shopu je bio cca. 8k - 10k

U sadasnjoj firmi gdje radim se nas shop takodjer vrti na shared hostingu, a imamo cca. 15k - 20k narudzbi dnevno, rasporedjen je na 8 servera ispred kojih je LB, prosjecno imamo oko 100k posjetilaca i nekih milion requesta dnevno. Mislim da je ovdje ukupno cca. 20 miliona varijacija proizvoda u pitanju, ili cca. 20k proizvoda.

Prema svemu navedenom nemam pojma koji je tvoj problem sa shared hostingom i zasto u svakoj temi koja se tice programiranja spominjes VPS. Jos k tome danas mozes za 50€ mjesecno i dedicated server dobiti, pa onda i u tom kontekstu ne vidin potrebu za VPS om, jer ako ces uzimati tako nesto onda se vise isplati uzeti Dedicated nego VPS ili odes korak dalje pa odmah uzmes Azure, AWS ili GCP.

2 Likeova

+1

Plus stripuje pola linkova iz view fajlova da izgleda jednostavno. Kad treba neka funkcionalnost, samo otkomentirati link po želji.

1 Like

Broj proizvoda nije bitan. Radio sam mini web shop sa 200 k proizvoda.
Bilo njih 200 K ili 2 K u bazi, tako svejedno.
Pošto znam kako rade baze koje imaju 800-900 M zapisa i radio sam s takvim bazama, meni je svejedno koja je količina u bazi, ali mi nije svejedno, što s tim podacima treba raditi u određenom trenutku.
Tako da mi 200 K zapisa ili 1 M zapisa u bazi izgleda smiješno.

1 M requesta dnevno, uzmimo 8 sati, ispada 35 requesta u s, na 8 servera, < 5 requesta u s po serveru. :slight_smile:

Kad kažem vps mislim na mašine kod AWS-a, digital ocean i sl.

Ako izbaciš iz računice peak time. Ne ide to baš linearno.

Ali onda računaš recimo realno 16 h dnevno (7-23 h npr.), a peak je koliko? 40-50 r/ s po serveru.

Ako imaju toliko narudžbi dnevno, onda mogu platiti i nešto više od shared hostinga.:sunglasses::sunglasses:

MS na azuru po mašini nudi čak do 500 i nešto cores. :grinning::grinning:

Ako ti treba 50 cores ili 100 cores, a nije tako skupo za onog tko zarađuje s time, no problem.

Problem je za onoga tko tek kreće sa web shopom, platiti cloud.

Gledao sam magento, opencart, presta shop, Sylius, shop ware, međutim to su ogromni web shopovi , a takav custom web shop košta.

Prije bi’ rek’o da ima 2 peak time-a sa po 2-3 sata svaki i da oni uzmu 40%-60% prometa.
Dakle 400k na 6 sati je nešto odakle bi’ započeo račun. 1/sec prosjek peak time-a (možda skoči i više ali 1/sec je prosjek).
Nije to problem za shared. Jedini problem je pouzdanost servera a ne sumnjam da ima i pouzdanih.

Dođeš na isto. 18 r /s / 8 servera = 2.3 r/s po serveru, peak nek bude opet 50 tu i tamo.

400 K * 2.5 = 1 M
6 h * 2.5 = 15 h
:sunglasses::sunglasses:

Ako je 60 % onda ispadne 27.22 r/s /8 = 3.5 r /s po serveru.

Vrtimo se u krug.

Nije ti dobar račun.
1/sec je u peak time-u.
Kad nije peak time onda je od <0.3/sec - 1/sec.
Ali slažem se da je besmisleno raspravljati jer i tih milion može biti 100k ili 5m i masa drugih varijabli može varirati.

1 Like

Nije mi jasno…

Singleton je anti-pattern

recimo da je tako…

Ako zelis uvijek dobiti jednu te istu instancu necega u lifecycleu requesta, vidi service locator pattern.

…nije mi jasno, kako se rjesimo anti-paterna pomocu locator patterna. Zar pomocu njega ne lociramo “jednu te istu instancu necega” koja je jos uvijek anti-pattern.
Isto i kontenjer, ako iz kontenjera izvadimo “jednu te istu instancu necega”, ona ce i dalje biti singelton tj jedna te ista instanca necega.

Točno. Možda sam se malo nespretno izrazio iznad - anti-pattern je i dalje, ali na ovaj način bar imaš nekoliko pluseva: izbjegava se skrivanje dependencija (obično se singleton implementira tako da se u globalnoj varijabli drži referenca na njega umjesto da netko to odradi za tebe, npr container). Plus ako se koristi DIC i sve je injectano onda je lakše testirati (pod tim mislim pisati testove) nego kada imaš statičke pozive posvuda.

Ok, to ima smisla.
Hvala.

Pratim ovo?
https://designpatternsphp.readthedocs.io/en/latest/More/ServiceLocator/README.html

:sunglasses::sunglasses:

Nismo se mozda dobro razumjeli onda. Zelis da netko za tebe resolvea dependencye (tzv container), i idealno zelis da svaka klasa u konstruktoru ima navedene sve dependencye o kojima ovisi, a ne da ih se skriva (npr singleton i globalni state koji sam spomenuo u nekom od ranijih postova).

Ne zelis da ti klase imaju dependency na service locator, pa da onda u tim klasama kroz service locator trazis servise. To i jest anti-pattern kako je i opisano na linku koji si dao.