Melyik keretrendszert tanuljam meg?
Elérkezett az idő, hogy végre magas szinten megtanuljak egy keretrendszerben programozni. Ha most megkérdezném tőled, hogy melyik keretrendszert válasszam, Te melyiket ajánlanád?
Milyen főbb különbségek lehetnek a keretrendszerek között, és egyáltalán milyen szempontokat kell figyelembe venni egy keretrendszer választásánál?
A nagy cégek általában milyen keretrendszert használnak php alkalmazások fejlesztésére, és mi alapján döntenek egy keretrendszer mellett?
Ha Te használsz valamilyen keretrendszert, akkor esetleg leírhatnád röviden, hogy szerinted mik az erősségei, gyengeségei, illetve ha váltottál keretrendszert, akkor azt miért tetted?
■ Milyen főbb különbségek lehetnek a keretrendszerek között, és egyáltalán milyen szempontokat kell figyelembe venni egy keretrendszer választásánál?
A nagy cégek általában milyen keretrendszert használnak php alkalmazások fejlesztésére, és mi alapján döntenek egy keretrendszer mellett?
Ha Te használsz valamilyen keretrendszert, akkor esetleg leírhatnád röviden, hogy szerinted mik az erősségei, gyengeségei, illetve ha váltottál keretrendszert, akkor azt miért tetted?
Ahogy én (gyakorlatilag
Előveszed az egyiket, ha van elég időd, pár hét alatt kapsz valami fogalmat róla, hogy mennyire áll kézre. Akkor félreteszed, elő a másikat, eljátszod ugyanezt. Esetleg ha van harmadik jelölted is, akkor azzal is. Ezek után nagyjából el tudod dönteni, hogy mi az, ami neked leginkább megfelel és azt kezded használni.
Ami hirdetést láttam, azokban többnyire előnyként és nem feltételként szerepelt x vagy y keretrendszer ismerete.
Framework függetlenül, amit
Amúgy Symfony 1.4-ről tudok egy pár jó szót mondani, előnye, hogy nagyon jól lehet benne plugin-eket (sf 2-ben már boundle a neve) készíteni, azok egyes részeit felülírni anélkül, hogy az eredeti pluginhoz hozzányúlnál, ami a kód újrahasznosíthatóság miatt előnyös.
Másik nagy előnye (ami sf 2-ben még nem tökéletes, de 2.1-re azt mondják lesz már benne), az admin generátor, egy console parancs kiadásával egy adatbázis táblához legenerlálja neked az admin felületet, ahol a tábla bejegyzéseit szerkesztheted. Mindezt olyan formában, hogy nagyon könnyen és gyorsan lehet átalakítani, új funkciókat beletenni, egyes részeit megfelelő jogosultsághoz kötni.
A formok kezelésében is nagy segítséget nyújt, objektum alapú, egymásba ágyazható formok, validálás. Egy-egy form mező (widget) maga is egy objektum, egyedi igény esetén írhatsz sajátot (pl.: autocomplete mező)
Pont a moduláris felépítése miatt sok plugin létezik hozzá, sf 2-höz is már rengetek boundle készült.
symfony 1.4
symfony 2
Egyszerűen programozható
Nekem a fő szempont, hogy a keretrendszerekhez képest viszonylag gyorsan és egyszerűen lehessen létrehozni webalkalmazásokat. Azt olvastam több fórumon is, hogy egyszerűség és gyors fejlesztés szempontjából a cakePHP és CodeIgniter azok, amelyek ezt a vonalat képviselik. Azonban azt is hallottam, hogy mivel nem kötik meg túlzottan fejlesző kezét, nagyon nagy projekteknél esetleg nehézkes lehet a kód újrahasznosítás.
A másik, amit hallottam, hogy a tapasztalt profik inkább a Zend és Symphony keretrendszereket említik, mivel nagyon jó a kód újrahasznosíthatóságuk, és megkövetel bizonyos konvenciókat, tehát nehezebb bennük fejleszteni, de egy több programozós csapatban és nagyon nagy projekteknél ezek az ajánlott keretrendszerek.
Én jelenleg egyedül dolgozom egy viszonylag kicsi projekten, tehát nekem a legfontosabb először is, hogy én magam átlássam a kódot, és gyorsan, egyszerűen tudjam fejleszteni, ne legyen benne sok konvenció.
Vélemény? Ki mennyire ért egyet? Kinek mi a tapasztalata az említett keretrendszerekkel?
jók a konvenciók
A kódgenerátorokkal az alapvető problémám, hogy a kezdő ismerkedővel nagyon gyorsan elhitetik, hogy baromi gyorsan megy itt a munka, alig kell hozzányúlni. Aztán amikor egy egyszerű módosítást végig kell vinni a rengeteg gyártott osztályon és sablonon, akkor derül ki mennyire nem így van.
Mivel nem te állítottad össze azt az osztályt, sablont nincs róla egy átfogó képed, hogy ha A ponton értéket adunk egy változónak, azt B helyen milyen módon lehet majd elérni.
Ha keretrendszert szeretnél választani kb a következőket kell tisztázni:
Látom értesz hozzá
Tudnál konkrét példát mondani, hogy szerinted mely keretrendszer valósítja meg ezeket a legjobban?
Te milyen keretrendszer(ek)t preferálsz? Miért?
nézd meg mindet
Pl.: legyen a feladat egy vendégkönyv. Semmi értelme, de nagyon jól lehet tesztelni azt, hogy hogyan kezeli a framework az űrlapokat. Hogyan lehet egy formot felépíteni, az onnan kapott adatokat validálni, beengedni az adatbázisba. Kiderül, hogy a rendszerrel mennyire lesz szívás az XSS támadások kezelése. Kiderül milyen körülményes lesz egy adatbázis utasítás végrehajtása.
Tapasztalatom a már említett Zend és Yii rendszerrel van. Zend-et kb a 0.6-os verziótól az 1.10.valameddig napi rendszerességgel használtam. Volt olyan projekt, aminek a fejlesztése az 1.1-es Zend verzió környékén fejeződött be, és komolyabb problémák nélkül folyamatosan tudtuk alatta upgrade-elni a keretrendszert. Korábban már említettem, hogy a Zend egy számomra szimpatikus modul könyvtár szerkezetet használ, ahol a beállításokon keresztül ezeket a könyvtárakat is átnevezheted, akár át is helyezheted. Igazság szerint a Zend Framework, a többi rendszerhez viszonyítva (CodeIgniter, Symfony, Yii, CakePHP, Kohana) nem is keretrendszer, inkább egy hatalmas kódkönyvtár, amiből azt használsz, amit jól esik (a keresztbe függések miatt ez sajnos nem minden esetben teljesül). A legjobb példa erre, hogy egy csomó tutorialt találhatsz a Zend_Db Propel vagy Doctrine rendszerre való cseréjére. Saját front controllert akarsz használni? Hajrá! Írd meg hozzá és használd azt. Nem tetszik a Zend_Loader és a vele szállított autoloader? Cseréld le nyugodtan! Smarty-t szeretnél használni View rétegnek? Nem feltétlen tartom jó ötletnek, de ez is megoldható.
A másik rendszer, amivel volt szerencsém közelebbről megismerkedni, az a Yii. Fogalmazzunk úgy, hogy a Zend után nem volt a legkényelmesebb rendszer. Az előbb leírt komponens cseréket egyáltalán nem olyan egyszerű megvalósítani. Azt nem merem leírni, hogy nem is lehet, mert annyira azért nem kerültünk közeli ismeretségbe. A legnagyobb problémám a Yii-vel, hogy olyan pontokon ad teljesen szabad kezet a fejlesztőnek (mondhatnánk úgy is, hogy ott engedi el a fejlesztő kezét), ahol szerintem egy jó rendszernek épp terelni kellene a jó megoldások felé. Viszont az olyan jellegű módosításoktól, mint a fentebb leírtak is nem könnyű letolni a torkán.
Az viszont tény, hogy erőforrás igényben - sajnos - a Zend messze lemarad pl a Yii mögött. Pl ez is lehet egy olyan szempont, amit mérlegelni kell egy rendszer fejlesztése előtt.
Adatbázis kezelés
Én a Zend adatbázis csomagolóját használom, azzal pl. nem kezelhető a FORCE INDEX, a csoportos INSERT és az összetettebb lekérdezések sem. Tervezési okok miatt nincs benne pl a mysql specifikus REPLACE.
Így az alkalmazás lekérdezéseinek kétharmada hordozható, a többi meg kézzel összerakott. Erre meg minek az ORM, ha esetleges adatbázis motor váltáskor úgyis buherálni kell a kódot?
..
Miért van rá szükséged?
Nemcsak előnyökkel jár egy ilyen környezet, hanem hátrányokkal is, amit sokszor "elfelejtenek" megemlíteni.
- plusz egy réteget hoz be a szoftverbe, amit meg kell tanulni
- az általánosan megírt kód miatt a futás lassabb lehet, mintha te készítetted volna el ugyanazt a funkciót
- ki kell tapasztalni a hibáit, korlátait
- az optimalizálás nehezebb, mert meg kell érteni a teljes működést
- verzióváltáskor nagy eséllyel írhatod át a kódot, mert szoktak változtatni a függvények paraméterezésén
- függsz egy harmadik féltől, a fejlesztést bármikor abbahagyhatják, és akkor bajban lehetsz
- ha helyből egy keretrendszerrel kezdesz, sok folyamatot elrejthet a szemed elől, és ezeket a problémákat nem tanulod meg megoldani
Szerintem akkor éri meg velük foglalkozni, ha a feladatod nem több egy-egy egyszerű CMS összedobásánál, ahol a cél az, hogy egy általános rendszert minél hamarabb elkészíts. Amint összetettebb problémát kell megoldani, előjöhetnek a fent említett hátrányok.A jelenlegi munkámat én is egy kliensoldali keretrendszerrel kezdtem (ExtJS), aztán az lett a vége, hogy szép lassan megszabadultam tőle. Egy példa: egy bizonyos objektum forrása ott több mint 600 sornyi volt és négy objektumhierarchián keresztül öröklődött, míg én ezt megoldottam 200 sorból, egy szinttel.
saját rendszer
Ezeket tapasztalatbol irom, mert a cegnel ahol dolgozom mi is evekig sajat rendszert hasznaltunk, aztan a sokadik programozo felvetele utan arra jutottunk, hogy lehet egyszerubb lenne egy open source framework-re atterni, mert sokkal konnyebb az ujoncok betanitasa es meg sokminden mas.
Igazad van
..
ami meg nalunk a sajat rendszerrel gond volt, hogy fejleszteni kellett folyamatosan es ez bizony eroforras. a nyilt rendszernel viszont tobben fejlesztik a rendszert igy a fejlesztesre szant ido eloszlik. ha jol emlekszem Linus Torwalds mondta egyszer azt, hogy az open source azt jelenti, amikor mas elvegzi helyetted a munkat :). ugyebar a mai Linux kernel kodjanak, ha jol tudom o kb 20%-ert felelos, megis az o projectje.
szerintem a legjobb az, ha az ember valaszt olyan open source frameworkot ami kozel all hozza, es annak a fejleszteseben segitkezik, igy adva vissza a fejlesztoi kozossegnek az ingyenes eszkozert valamit.
de egyebkent mindenki azt hasznal amit szeretne. en csak a sajat tapasztalatom alapjan tudom azt irni, hogy nekem konnyebb az eletem, amiota sajat rendszerrol, open source framework-re alltunk at. foleg miota a yii githubra koltozott es igy konnyen lehet kozremukodni a fejlesztesben.
Mindkettőnek van előnye és
A problémák a keretrendszerekkel ott kezdődnek, ha felfedezel bennük valamilyen hibát, és javítani szeretnéd. Saját rendszernél ennek nagyon gyors átfutási ideje van, egy keretrendszernél viszont ehhez képest rengeteg időbe telik, míg bekerül egy javítás, és akkor az új feature-ökről ne is beszéljünk.
Szerintem olyan rendszert érdemes választani, ami könnyen módosítható, az egyes osztályok könnyen lecserélhetőek benne. Jó jel, ha sok interface-t definiál, mert az valószínűsíti, hogy cserélhetőek benne az osztályok. Megintcsak jó jel, ha rövidek az osztályok (50-100 sor), és dependency injection-t használnak. Persze az optimalizálás ronthat ezen. Megintcsak jó jel, ha vannak unit test-ek és integrációs tesztek hozzá, ezekből még akár tanulni is lehet azzal kapcsolatban, hogy mi az elvárt viselkedése az egyes osztályoknak.
Javasolni egyelőre nem tudok egy rendszert sem, mert csak átfutottam őket. Ami szimpatikus volt, az a Zend és a Symfony, de túlbonyolítottnak éreztem őket. Ez még a régebbi verzióknál volt, azóta biztosan ezek is letisztultak. Én mindenesetre elkezdtem egy saját rendszer fejlesztését, sokat tanultam belőle, pl azt, hogy ez nem öt perces feladat, szóval ha megbíztak egy projekttel, akkor egy létező rendszert használj, ne kezdj el sajátot fejleszteni. Ha nincs határozott elképzelésed, hogy mit vársz egy ilyen rendszertől, akkor bele se kezdj, mert esélytelen, hogy használható kódod lesz a végére. Egy saját rendszer így is csak hónapok után érik meg a használatra, onnantól viszont nagyon nagy előnye lesz a többi rendszerhez képest, hogy te fejleszted, kívül-belül ismered, minden gyorsan megy benne, és akkor módosítod, amikor csak akarod, ha hibát találsz, vagy valami új feature-t akarsz beletenni, sosem fog bezavarni a következő verziófrissítés... Persze ettől függetlenül én is át fogom nézni az új Zend-et és Symfony-t, mert érdekel, hogy hogyan oldották meg a problémákat, amikkel összetalálkoztam a saját rendszeremnél.
Ezen a fórumon szinte csak
Egy kérdést tegyél már fel magadnak: Egy szoftvernek jó esetben sokkal hosszabb az életciklusa, mint a fejlesztési ideje. Ha te rendelnél egy szoftvert, tényleg örülnél annak, ha csupa egyedi - többnyire szar - megoldással implementálnák azt, vagy jobb lenne, ha egy ismert, nyílt forráskódú keretrendszert használnának, amihez a jövőben esetleg más is hozzá tudna nyúlni?
Nyilván te jobbat tudtál írni, mint az ExtJS, ez nem vitás.
No ezt nem fogom soha megérteni...
Úgy őszintén: fejlesztőnek hol érdeke, hogy az általa írt programba később más is bele tudjon piszkálni, ne őt keressék meg a fejlesztési igényekkel? A megrendelő - legalábbis nagyvállalati körökben úgy tűnt, ez a helyzet - inkább ad a szoftver minőségére, mint arra, hogy később esetleg más fejlesztővel dolgozhasson tovább ugyanazon a szoftveren. (szoftver minőségén a megbízható, gyors működést, könnyű üzemeltethetőséget értem, nem a szép és olvasható kódot)
Szóval nekem úgy tűnik, amellett, hogy totál felesleges lehülyézni másokat, most még igazad sincs.
Nem hülyéztem le. Lehet
Lehet széllel szembe hugyozni, csak nem érdemes. Kaptál te már más fejlesztőtől régi - egyedi - kódot? Ha dolgozol egy ideje, akkor biztos vagyok benne. Hányszor fogtad a fejed? Hányszor anyáztál? PHP-s körökben sajnos pont az ilyen fafejűség miatt vannak ilyenek. Nagyvállalati körökben általában nem PHP-t használnak (tekintsünk el a kisebbségtől) és tényleg szabványokat használnak. Igazi szabványokat és de facto szabványokat. Mindenesetre olyat, amiről hallottak már a déli féltekén is.
Az, hogy te összehegeszted a kódot egy általad összetákolt, nulláról megírt libraryvel, "keretrendszerrel", adtál a szarnak egy pofont. Két év múlva a megrendelő, a cég, ahol dolgozol, de még Te magad is elátkozod azt a percet, amikor nekiláttál a munkának. Ha ehhez két évnél több kell, akkor arra se vagy alkalmas, hogy felismerd a hibáid -> hagyd ott a programozást és kezdj valami másba.
-
Személyeskedés
Nem mertem Poetrora
Saját és nyílt forrású
A nyílt keretrendszerek egy-egy problémára általános megoldást adnak, ami mindaddig jó, amíg speciális igény nem merül fel, például beágyazott környezetben is futnia kell a programodnak, vagy épp ellenkezőleg, elosztott rendszerben. Ilyenkor előnyben lehet az, aki nem keretrendszeren nőtt fel, és a programnyelv segítségével közvetlenül is meg tudja oldani a problémát.
A következőkben legyél szives
yii
Hallottam róla
Elmondanád, hogy neked személye szerint miért tetszik?
Milyen tapasztalataid vannak a Yii-vel kapcsolatban, és ha esetleg van hátránya, mi az?
..
Ami szerintem pozitivum, hogy nincs felesleges sallang. Van egy jo routing, egy jo ORM(ActiveRecord), ami szerintem a 2 legfontosabb dolog egy frameworknel. Ezen felul konnyen kiegeszitheto, es a kiegeszisek konnyen ujrahasznosithatoak mas projecteknel is.
Ami szerintem pozitivum, hogy
Az biztos. Nézd meg a CHtml-t, tömör gyönyör. 2200 sornyi statikus metódus.
nem hiszem hogy azok a
Tényleg nem az. Ha kicsit
bar az igaz hogy ezen a
Hát kb 100 statikus metódusa
Érdekes statisztika
Zend, CodeIgniter, Symfony, Yii, CakePHP népszerűségének időbeni összehasonlítása
Illetve másik játék:
CodeIgniter, Symfony, Yii, CakePHP népszerűségének időbeni összehasonlítása
Nagyon érdekes statisztika, ki mit gondol róla?
Re: statisztika
Attól persze óva intenélek, hogy ZF-fel indítsál. Többen leírták már, hogy kezdésnek egy könnyedebbet érdemes választani, én a Kohana-t ajánlanám. (indokolni nem tudok, szubjektív szimpátia:) Utána, ha lesz egy reális képed arról, hogy mit is vársz el egy keretrendszertől, akkor már könnyebben tudsz választani az erősebb rendszerek közül!
kohana
Ezt most nem biztos, hogy értem...
Magukat elegáns HMVC-nek hívják, eddig nem gondoltam volna, hogy gond van ezzel. :)
..
egyszer valaki segitseget kert kohana-val kapcsolatban es errol az oldalrol probalta a mintat probalta megcsinalni. En itt csak annyit lattam hogy a POST-on hivja meg a validalast a framework, a controller-ben. Mostmar latom, hogy ezt barhol megteheted. egyebkent szerintem nem GET es POST adatokat kellene ellenorizni, hanem a model bizonyos attributumait mielott erteket kapnak es ha nem a megfelelo erteket probaljuk atadni, akkor azt nem elfogadni es egy hibat generalni. Ez az ertekadas meg ugyebar tobbfele keppen lehetseges. Johet POST-bol, GET-bol, stb.
Előfeltétel
...nem rossz az, ha a klienstől jött adatokat előszűrjük. A modell ne arról szóljon, hogy mindenféle típusellenőrzést végezzünk ott. Ha számot várunk az url-ből, akkor azt még a kontroll alakítsa számmá, a kontroll ne adjon „hibás” értéket tovább. Igaz, ezek csak formai ellenőrzések, illetve átalakítások. Amit te írtál, azok csak ezután jönnek, a modell is végezze el a maga ellenőrzéseit a logikai összefüggések kapcsolatba. De ott már hadd tételezzük fel, hogy pl. az id az egy szám, legyen ez a modell előfeltétele.
az a baj, hogy ha a peldak
az url-bol jovo adatokat szerintem mar a route-ok feldolgozasanal ellenorzni kell, ha azt a routenal megadod hogy milyen pattern-nek feleljen meg.
+1, akkor azt hiszem
Alapvetően a modelben vannak
http://kohanaframework.org/3.2/guide/orm/validation
http://kohanaframework.org/3.2/guide/orm/examples/simple
Pontosabban van lehetőség bizonyos ellenőrzések elvégzésére a controller-ben. Pl. a captcha ellenőrzés nem a model feladata.
Egyébként jó pár fw megnézése, és a számomra fontos szempontok kiértékelése után nagyon gyanús, hogy a Kohana3 lesz a befutó, hacsak a Zend Framework 2 nem lesz elképesztően jó, ha kijön végre...
Zend != Zend Framework
Egyébként szerintem kezdj a CodeIgniter-rel mert egyszerűbb, mint a többi, a dokumentációja pedig kiváló. Utána, ha ezt az egyszerű keretrendszert megismerted, úgy is meg fogod nézni a többit is. Ha pedig már 3-4 keretrendszert megnéztél közelebbről - azaz heteket töltöttél el velük -, akkor már fogsz tudni választani.
Symfony 2
Nálam toronymagasan a Symfony 2 a győztes, mondom ezt úgy, hogy legalább egy projekt erejéig volt szerencsém a következőkhöz: CodeIgniter, Kohana, Zend, CakePHP, írtam egy sajátot, és részt vettem egy céges fejlesztésében is.
Mindenképpen ajánlom, hogy próbáld ki, következők miatt:
- Új, de már kinőtte a gyermekbetegségeket, hosszabb távra leszel jó vele, mint mondjuk egy olyannal ami éppen átírás előtt áll. (Szerintem ez az egyik legfontosabb szempont)
- Ha már kicsit belejössz, akkor nagyon könnyen átlátod, mert minden teljesen logikus, annak ellenére, hogy az elején szokatlan.
- A Symfony és a Zend kivételével mindenhol kicsit az az érzésem volt, hogy két fal közé vagyok szorítva, csak egyféle lehetőség volt, a többit úgy tákolták hozzá. Itt lehetőség van választásra, ha neked xml a kedvenc, akkor abban dolgozol, ha annotation akkor abban. Persze választási lehetőség nem csak a configra van...
- Elképesztően jó Router, és Form kezelés, ez mindig az egyik első dolog amit megnézek egy frameben.
- Doctrine 2 nuff said
- Dependency Injection Container(aka Service Container): Szerintem a Symfonys srácok ezt nagyon eltalálták, igenis van létjogosultsága PHPben is.
- Full stacked... nem kell feltalálnod a spanyol viaszt, de ha akarod megteheted.
Hátrányként 2 dolgot tudnék említeni:
- Nincs hozzá még jó CMS rendszer. Próbálkozások persze vannak, de olyat még nem találtam, amire azt mondom, hogy ez igen. ( Lehet hogy ez inkább lehetőség valamit alkotni? :) )
- Ha egy exceptiont kapsz valahonnan mélyről, akkor elég nehéz dolgod van (az elején). Persze itt nem arra kell gondolni, hogy minden apróságért órákat debuggolsz, az esetek nagy részében teljesen egyértelmű a hiba. Erre egyébként van már egy javítási kísérlet 3. személytől, de még nem próbáltam, már nem igazán futok bele ilyenbe.
+ 1 Tipp: ha már pár napot eltöltöttél vele, és azt látod, hogy nagyon sok olyan dolog van benne, amit lehetne sokkal egyszerűbben is, akkor ne dobd ki, kitartás! Először én is így voltam vele, aztán jöttek a nagy ledöbbenések "Hihetetlen, hogy erre is gondoltak" címmel.
Remélem segítettem.
Köszönöm
Nálam jelen pillanatban az utóbbi napok kutatása alapján a codeIgniter a befutó. Tudnál mondani valamit erről a keretrendszerről is? Neked miért nem tetszett a codeIgniter?
CI sem rossz
Azt nem mondanám, hogy nem tetszett, inkább fogalmazzunk úgy, hogy kicsit kevés nekem.
Nem php 5.3 as, Model elég vékony, Form osztály gyakorlatilag nincs, csak egy validáció, ami elég szerény, és egy helper, amivel meg tényleg nem mész semmire...
Amiért szerintem népszerű, az a viszont pont az egyszerűsége... egy Symfonytól meg Zendtől nagyon sokan megijednek.
Smyfony2 első keretrendszernek?
De ha mindezek nem lennének, szerintem akkor sem ajánlható nyugodt szívvel első keretrendszernek.
Ez már nem igaz, bár fél éve
Az hogy első keretrendszernek mennyire jó, az szerintem tudásszint függvénye.
Én is sok buggal találkoztam
Nem hiszem, hogy sok, keretrendszert eddig még nem használó fejlesztőnek ideális kezdés lenne. Honnan is lenne meg a tudás, ha a tudás egyik alapköve pont a keretrendszer használat? Szerintem az élet minden területén végig kell járni a lépcsőket...
Ha egy exceptiont kapsz
Ez tervezési hibára utal, a magasabb absztrakciós szintű osztályoknál try-catch-be kellett volna tenni, az olyan metódusokat, amik alsóbb szinten kivételt válthatnak ki, és új kivételt példányosítani hozzájuk, ami magyarázza a hiba okát. Durván valami ilyesmit kéne csinálniuk:
Az órisáprojektek
Kiváncsi vagyok, hogy az olyan világcégek mint a Google, a Facebookb stb, amelyek webre fejlesztenek kifejezetten, milyen keretrendszereket vagy megoldásokat alkalmaznak? Bár gondolom ott a számítások nagy része inkább valamilyen gépközeli nyelven történik pl. C++, és onnan kerülnek vissza az eredmények pl. php-ba, de az már csak egy view réteg. Nem tudom, csak sejtem, hogy így történhet.
Tud valaki valamit arról, hogy az ilyen gigantikus projektekben mi a módi manapság? Bár az már más kategória nyilvánvaló.
Volt párszor blogmark a
Óriásprojekt?
Keretrendszerekről
A keretrendszerek lényege, hogy viszonylag olcsón és a lehető leggyorsabban megkapod funkciójában azt, ami kell. Egyrészt ez az esetek 99,99%-ban elég. Főleg, ha egy Start-up ötletről, cégről beszélünk. Elkészül az oldal, úgysem kap egyből 1 000 000 kérést per másodperc. Az oldal fejlődésével, az igények változásával pedig lehet bővíteni a vasak számát, a keretrendszerben lehet elosztott rendszert fejleszteni, lehet optimalizálni adatbázis oldalon - memóriába pakolni a fontosabb adatokat, cache-elések, stb. Egy FB esetén pedig megoldható, hogy a fejlesztés lassabban menjen - vagy több emberrel -, viszont "pure" php-ban készüljön az egész, esetleg C-ben vagy ahogy tetszik, mert ott már az is számít. De ez az esetek 0,0001%-a, és ott már nem egyéni fejlesztőkről beszélünk, meg nem arról, hogy van 2 000 000 Ft induló tőke...
Előfeltételek
Először érdemes lenne PHP OOP programozást gyakorolnom, vagy anélkül is belevághatok?
Ha előtte azt kell gyakorolnom, mi erre a legjobb módszer? Olvassam át ezt?
http://www.php.net/manual/en/language.oop5.php
egyreszt OOP, masreszt a
Kezdd el, aztán idővel