[PHP/PEAR] Wat zijn de voordelen van een PEAR-package?

[Verwijderd]

Hallo,

Na een hele poos heb ik php maar weer een uit de kast gepakt, na alweer een ruim een jaar .Net geprogrammeerd te hebben. Ik was weer gevraagt om een webapplicatie(tje), die ik ooit eens gemaakt had, uit te breiden. Dit was nog gemaakt in PHP4 met een poging tot OO.
Ik heb een boek aangeschaft : PHP5 Objects, Patterns and Practice (isbn: 1590593804), om weer een beetje op de hoogte te zijn van PHP5 en de mogelijkheden.

offtopic:
Het is best een goed boek en je geheugen een op te frissen en een aantal nieuwe mogelijkheden te zien. Of het echt een boek is om uit te leren betwijfel ik. Maar het laat duidelijk zien dat een aantal dingen kunnen in php, zoals patterns.

Nu wordt in het boek veel gebruik gemaakt van PEAR, het is ook een hoofdstuk uit het boek. Nu leek het handig om een aantal packages te gebruiken. Ik had mijn eigen MySql wrapper geschreven in mijn vorige project. Nu leuk het me handig om deze te poorten naar PEAR:DB.

Ik heb de package "geinstalleerd" en ben er wat mee gaan stoeien en heb ik in de source gekeken wat het nu allemaal deed. Maar wat me opviel, de package is nogal traag en dan heb ik het nog niet eens over het query'en. Ik heb wat gegoogled en op het forum gezocht ([PHP][PEAR] Performance issue tov rectstreeks mysql). Hieruit blijkt zelfs dat PEAR::DB het query'en zelfs ook nog vertraagd. Ik vond het al beroerd dat het includen/requeren al lang duurde.

Waar ik nu het hardste tegenaan kijk: Moet ik nu PEAR gaan gebruiken, of niet.

De PEAR::DB ziet er niet al te best uit en zal niet erg performen, naar mijn mening. Hoe denken jullie hier over? Wie gebruikt er PEAR packages, in het bijzonder PEAD::DB en hoe performen deze bij een redelijk "drukke" site/applicatie?
Wat zijn de alternatieven, ik heb zelf een MySql wrapper geschreven, die opzich goed werkt. Alleen zal ik deze moeten hetschrijven als ik een andere database wil gaan gebruiken. Iets wat ik hoogst waarschijnlijk niet zal doen. Als enige alternatief zie ik het zelf schrijven.

[Nielsz]

Ik werk nu een aantal jaar als PHP programmeur. Ik heb nog nooit te maken gehad met PEAR classes.
Zelf bouwen is vaker sneller dan helemaal opzoeken. En als ik hele ingewikkelde grote dingen ga maken, dan wil ik elke regel zelf gemaakt hebben zodat het perfect voor mij is.


Een mysql wrapper omschrijven naar bijvoorbeeld postgres is niet zo'n probleem hoor. Mijn wrapper moest laatst ze allebei aankunnen. Heel simpel als private var je type zetten, en bij elke function een check doen, en dan postgres_query ipv mysql_query doen. Ben je toch in een uurtje mee klaar.

Verder, als je van db type verandert, moet je toch al je queries nalopen.
_{MySQL: SELECT * FROM tbl LIMIT 10, 5 Postgres: SELECT * FROM tbl LIMIT 5 OFFSET 10}

[ Voor 13% gewijzigd door Nielsz op 05-08-2006 22:33 ]

[XWB]

Geen ervaring met PEAR, net als Nielsz schrijf ik alles liever zelf (op een paar zaken na). Als je PHP > 5.1.0 staan hebt moet je eens naar PDO kijken: http://www.php.net/pdo

[Soultaker]

Het idee van PEAR is dat het een package repository voor PHP is, te vergelijken met CPAN voor Perl. Het voordeel van PEAR packages gebruiken, is dan ook dat je zelf niet alles van de grond af hoeft op te bouwen, maar dat je betrouwbare, werkende code van het internet kunt halen.

Praktijkervaringen heb ik er niet echt mee; ik schrijf ook (veel te vaak) mijn eigen library code. Wel is het zeker in PHP zo dat abstractie ten koste van rauwe performance gaat, maar dat geldt voor zelfgeschreven abstracties net zo goed.

[frickY]

Ik sluit me ook aan bij Nielsz. Script nu een ruime 6 jaar in PHP, en heb nooit naar PEAR gegrepen.
Eens een artikel over gelezen, en eens wat broncodes bekeken, maar zag er het voordeel niet zo van.
Net als Nielsz schrijf ik liever alles zelf zodat ik weet wat wel kan, en wat niet kan.

Zeker omdat je aangeeft niet verwacht ooit naar een andere databaseomgeving te willen overstappen, zie ik geen reden waarom jij wel PEAR::DB nodig zou hebben.

[Sybr_E-N]

Eigenlijk wel totaal inefficient als elke PHP-er alle libraries zelf gaat programmeren. Waarom niet een kant-en-klare lib gebruiken, die volledig is en al goed uitgetest? Scheelt je echt weken, zo niet maanden zelf implementeren.

Ik denk dat de meeste PHP-ers niet commercieel PHP inzetten, want dan scheelt zo'n standaard library(-ies) gewoon veel geld en tijd. Helemaal uitzoeken hoe zo'n framework in elkaar steek, en dat dat veel tijd kost is natuurlijk kul. Met een goed opgezet public framework kun binnen een aantal minuten aan de slag, om de meeste voor de hand liggende zaken te gebruiken. Stel je voor zeg, je moest eens in de help files kijken... Het zelf bouwen van een abstrace data laag in PHP, voor ondersteuning van verschillende database's zal altijd langer duren dan het gebruiken van een Pear classe.

Btw ik gebruik, als ik PHP gebruik, PEAR zelf ook nooit . Waarom? Ik denk, net als de meeste andere PHP-ers, omdat je het zelf eens een keer graag wilt gaan maken. Alles zelf mogen bedenken en uitvoeren. Dat is het mooie van programmeren, niet waar. PHP gebruik ik voor de hobby, dan wil ik juist dat soort zaken eens een keer zelf doen.

Tegenwoordig beginnen de mannen van PHP ook zelf met ingebouwde stukken software, zoals dat mysqli in OOP gebeuren.

Het heeft mij altijd verbaasd dat in de grote PHP communitie er weinig bekende frameworks zijn. Iedereen vind het nodig om zijn eigen dingen te maken. In andere ontwikkelomgevingen zijn er juist veel van dat soort zaken veel meer standaard aanwezig.

[ Voor 17% gewijzigd door Sybr_E-N op 05-08-2006 23:19 ]

[XWB]

Je vind het eerst inefficient als iedereen zijn eigen libraries gaat devven maar achteraf zeg je het zelf: "omdat je het zelf eens een keer graag wilt gaan maken".

Ik denk dat de meeste PHP-ers niet commercieel PHP inzetten, want dan scheelt zo'n standaard library(-ies) gewoon veel geld en tijd.

Tenzij je zelf een grote library hebt die je overal kan gebruiken.

[Verwijderd]

De meningen zijn hetzelfde als de mijne:
Waarom zou je code zelf schrijven als die voor het oprapen is, maar de betrouwbaarheid en performance is maar de vraag.

Ik vind proggelen heel leuk, maar waarom zou ik het wiel voor een 2e keer uitvinden. Maar als een standaard component (PEAR package) niet voldoet en er al een goed alternatief bestaat, mijn eigen wrapper, dan lijkt het voor mij niet echt nuttig om te gebruiken. Er zullen vast andere packages zijn die iets heel anders doen en wat veel werk kost om zelf te bouwen. Deze zullen wel interressant zijn om te gaan gebruiken. Maar PEAD:DB zal ik nog niet gaan gebruiken

[dingstje]

Nielsz schreef op zaterdag 05 augustus 2006 @ 22:32:
Een mysql wrapper omschrijven naar bijvoorbeeld postgres is niet zo'n probleem hoor. Mijn wrapper moest laatst ze allebei aankunnen. Heel simpel als private var je type zetten, en bij elke function een check doen, en dan postgres_query ipv mysql_query doen. Ben je toch in een uurtje mee klaar.

Dit vind ik persoonlijk niet zo'n goede oplossing. Zo krijg je snel boated code (als je met twee databases werkt kan dat nog meevallen, maar wat doe je met 4 databases en dan van sommige nog eens verschillende versies) die moeilijk te onderhouden zijn.

Ik ben persoonlijk meer fan van het volgende:

• Een klasse DBFactory met een getDAO() methode die een DAO-object teruggeeft
• Een abstracte klasse DAO met de standaard functies (fetch, execute, ...)
• Een concrete klasse die de DAO klasse overerft voor elke database die je wil ondersteunen

Dit concept is imho beter voor de managability. Je kan gewoon concrete DAO-klassen erbij gooien en wegnemen, afhankelijk van wat je nodig hebt. Je hoeft dan ook niet bij elke function call een if-clausule te doorlopen en je kan je code beter structureren.

Verder, als je van db type verandert, moet je toch al je queries nalopen.
_{MySQL: SELECT * FROM tbl LIMIT 10, 5 Postgres: SELECT * FROM tbl LIMIT 5 OFFSET 10}

Dat is inderdaad het grote probleem van SQL, de verschillende dialecten. Je zou iets kunnen implementeren als HQL (Hibernate Query Language) en dan voor elke engine parametrized queries laten genereren en die opslaan zodat je ze at runtime snel kunt gebruiken.

[CH4OS]

Ik heb een tijdje terug voor mijn stage ook met PEAR:DB moeten werken.
Op zich is de achterliggende gedachte mooi, jammerlijke is alleen dat het idd niet zo best performed dan je zou willen... Aangezien ik het moest gebruiken, heb ik het uiteindelijk maar gebruikt, omdat het een wens was van de klant, met als rede dat je dan makkelijk over kan stappen naar een andere DB server...

Maar moet wel toegeven, dat bij mij de pagina niet zo supertraag was en ik denk zelfs, dat als ik direct de mysql-functies er voor gebruikte, ik weinig verschil zou merken.

Moet er dan wel bij bekennen dat de webserver waar het op draaide best wel een beest was hoor...