2010. június 12. \\ geek témában
Persze roppant jó dolog az egész, de a PHP után kicsit (teljesne) más szemléletet igényel, mert persze lehet ott is tervezési mintákról beszélni, csak azért amikor beül az ember egy ilyen elé, akkor látja hogy mennyire vicces az egész, és hogy is kéne igazából mennie.
Subscribe to get the latest posts sent to your email.
"Pont mostanában volt élményem egy online..."
"köszi!"
"Boldog születésnapot neked is! Jó újra látni, ezer..."
"Szerintem szinte végig követtem a blogodat, én biztosan..."
"így legyen :D"
Írja és rendezi Mefi, avagy Nádai Gábor © 2005-2026
A blogot büszkén pörgeti a WordPress motorja, Anders Norén sablonjának átbuherált változatával.
ZoliKa
2010. június 13. — 01:43:53
milyen programnyelv ez?
Maerlyn
2010. június 13. — 10:37:29
Hibernate? Ha tetszik, akkor nézd meg ezt is: Doctrine.
Athos
2010. június 13. — 13:53:17
Azért a PHP védelmében annyit szabadjon megjegyeznem, hogy ez nagyon nem a JSP-n (vagy mi a csuda ez) múlik. A C# (+ASP.Net), a Java és a PHP is csak egy-egy nyelv, előbbi kettőben (vagy körül) van pár advanced dolog, ami a PHP-ból fájóan hiányzik (bár a PHP 5.3 azért némi lemaradást pótol ezen a téren), olyan cukorkákra gondolok, mint például a linq, de alapjáraton tényleg csak 3 nyelv, amik közül az egyik itt rugalmasabb, a másik meg ott. Ami a PHP-nál fájhat, hogy nem jár hozzá gyárilag egy nyelvhez drótozott egy framework (ami van, az a minimálisnál is kevesebb, épp csak arra elég, hogy a lehetőség meglegyen webezésre meg shell-script írásra), ez viszont pont, hogy előny is lehet. Szóval a PHP-t önmagában összehasonlítani a Java+JSP-vel vagy a C#+ASP.Net-tel kicsit unfair. Egy PHP+ jellegű összehasonlítás már inkább megállná a helyét, a valami helyére pedig keretrendszerek széles skálája helyettesíthető. (Ld: http://www.phpframeworks.com/ )
Mefi
2010. június 13. — 14:43:21
[re=6061377]ZoliKa[/re]: Java
[re=6061378]Maerlyn[/re]: ismerem a Doctrine-t. 🙂
[re=6061379]Athos[/re]: ez teljesen jogos, de azért a PHP és a Java között már mint nyelv is nagyon sok hiányosság van. Ilyet el tudsz érni Symfony vagy bármelyik hasonló kaliberű keretrendszerrel, tény. Meg annyira nem bántom a PHP-t, nem véletlen használom én azt. 🙂
Maerlyn
2010. június 13. — 14:49:09
Akkor talán azt is tudod, hogy a Doctrine 2.0-ában hasonlóan, annotationökkel tudsz majd osztály-DB kapcsolatot definiálni. Nem is az ActiveRecord mintára fog alapulni.
Másrészt: nemrég a php wikijében megjelent egy RFC az annotationökről, remélhetőleg behozzák itt is nyelvi szintű elemként, és akkor reflectionnal egyszerűbb lesz az élet.
Amúgy a symfony+doctrine integráció egyszerűen odabasz. Java-val és hibernate-el még nem foglalkoztam, de a lakótársam ebben kódol mostanság, és meglepően jól tudunk ezekkel kapcsolatban ötletelni, annyira hasonlóak.
Mefi
2010. június 13. — 14:53:23
[re=6061381]Maerlyn[/re]: egyébként sok a hasonlóság, igen. Amúgy jó dolog ez, az száz százalék, csak azért jócskán igényel tanulást is, mert elsőre annyinak tűnik hogy ő legenerál szépen mindent, aztán örülsz, de közben közel nem ez a helyzet.
saxus
2010. június 15. — 00:26:47
Pff. Annotációk. Nagyon jó, hogy az alap dolgokat meg basznak helyre rakni. Épp ma szopott be munkatárs egy aranyos SOAP finomságot, hogy ha egy adott értéket nem castol át int-té, akkor akkora exceptionnal elszállt a fogadó rész, mint a ház. Persze jogos, csak épp a PHP részéről a típuskezelés akkora egy hányadék, hogy az hihetetlen.
És az ilyen aranyosságokról, mint például az ebből következő crc32/64bit bugokról ne is beszéljünk.
saxus
2010. június 15. — 00:32:25
Jut eszembe, ActiveRecord, Doctrine, ésatöbbi ésatöbbi ésatöbbi. Pár hete azon elmélkedtünk munkatársakkal, hogy mégis mi a balherének kell azzal szívni, hogy először is húzunk egy OOP réteget a relációs adatbázis fölé, majd egy külön rétegben elkészítjük a modell részt, ahol látszólag megvalósítjuk a program működését.
Totál felesleges erőltetni a relációs adatbázisokat, ha egyszer nem úgy akarjuk használni őket. Sokkal célszerűbb lenne inkább valamilyen perzisztens objektumtár, mintsem szenvedni a relációs-adatbázisba való belegyömöszöléssel.
Ötlet egyébként onnan jött, hogy egy mintegy 60-70 táblára szétszedett adatszerkezetet kellett eltárolni, ami igazából egyetlen objektumból indult ki. Persze, ez nem a teljes DB, az egész áll vagy 270 táblából, dehát ilyenek ezek az ügyviteli rendszerek.
Mefi
2010. június 15. — 04:11:31
[re=6061393]saxus[/re]: típuskezelés? Az van a PHP-ben? 😀
[re=6061394]saxus[/re]: mondjuk jó dolog a Doctrine meg a többi, egy blogmotorra vagy egy átlag netes projektre, de én már komolyabb egyedi ötleteket sem feltétlenül bíznék rá. Elhiszem én hogy jó, de alapjáraton nem bízok a generált témákban, lehet hogy időigényesebb, de én amondó vagyok hogy minden program saját igényeket állít elő, és ezeket sajátos módon kell megvalósítani. (Persze egy framework használata az teljesen oké, csak érted mire gondolok.)
saxus
2010. június 19. — 01:07:07
[re=6061396]Mefi[/re]: Ezek szerint elbeszélünk egymás mellett. Szvsz sokszor felesleges lenne ma már erőltetni a relációs adatbáziskezelést.
Generált dolgok jó dolgok, csak ésszel kell intézni. Mi alapvetően megpróbálunk minden sallangmunkát generálni, mert időszűke az erősen megmutatkozik. Pl. az a 70 táblás modul, amit emlegettem az úgy készült, hogy először a saját DB leíró nyelvünkben definiáltuk az adattáblákat (kb. 5-8 db volt + a rengeteg kiegészítő tábla, ami mind generált egy adott szabály szerint), majd ebből építettünk adatbázist és „fapad” fájlokat.
Ennek a „fapad” dolognak megvan a maga belső sztorija, de most nem mennék bele. Lényege, hogy ezekből lehet adatosztályokat generálni.
Ezeknek az adatosztályok PHPDoc-s részét kiegészítve saját annotáció szerűségekkel, azokból generáltuk az űrlapokat, előzmény-táblázatokat. Utána már csak össze kellett pakolni egy halomba meg meg kellett jeleníteni őket (ez kb. 8 metódus megírását jelentette a modulban + a „popup”-ba felugró űrlapok/táblázatok megjelenítését és mentését kezelő három metódust.*)
Így sikerült egy kb. másfél hét alatt összerakni az egész modult, ahelyett, hogy kb. 2 hónapig reszeltük volna az egész modult.
* Minden egy sémára lett leegyszerűsítve, űrlapok kezelését lényegében a keretrendszerünk végzi, annyi, hogy megjelenítéskor tudatni kell a kerettel, hogy erre még később szükség lesz, valamint az egész cuccot visszakapom még a kerettől, amikor már lényegében csak menteni kell az adatokat – ami egy save() hívása az adatosztályra általában. Validálást és minden egyebet a keretrendszer elintéz. Megszenvedtünk vele anno, de így tényleg jóval kevesebb idő az egész bazár, mintha megírnánk mindent egyesével.