Hirdetés
- GoodSpeed: Ebes, a megtervezett falu!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- GoodSpeed: 3I/Atlas: Üstökös vagy idegen civilizáció űrhajója?
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Mr Dini: Mindent a StreamSharkról!
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- Luck Dragon: Asszociációs játék. :)
- Elektromos rásegítésű kerékpárok
- GoodSpeed: Márkaváltás sok-sok év után
Új hozzászólás Aktív témák
-
#15488
mallee
tag
Speeedfire
#15486
mallee
tag
válasz
Speeedfire
#15486
üzenetére
Tudsz mondani olyan esetet, ahol az addslashes jó?
-
#15485
mallee
tag
Speeedfire
#15484
mallee
tag
válasz
Speeedfire
#15484
üzenetére
Adatbázisos escapeléshez a prepared statement-ek valóak, de jó még a mysql_real_escape_string() is. Cookienál nincs mit escapelni. XSS támadás szűréséhez pedig megint más megoldások vannak.
-
mallee
tag
válasz
DNReNTi
#15478
üzenetére
Egy kicsit kritizálok, ha nem baj
Configuration
Az osztálynak van konstruktora, amely az általad linkelt kódokban sehol sem kerül meghívásra. Ezenfelül csak statikus változót és metódust tartalmaz, nem értem a szándékodat. Vagy legyen statikus osztály (inkább ne) vagy ne legyen az (inkább ez).Database_Connection
Továbbra is végez felesleges dolgokat, lásd ini_set. És hiába nem akarod, hogy belekössünk, bele fogunk
A display_errors amúgy is legyen kikapcsolva, a hibákat nem kiíratni kell, hanem loggolni.
A die() helyett hagyd az exception-t "felbuborékozni" és egy másik szinten kezeld le a hibaoldalt.Database
őőő, ez így nem az igazi szerintem. De majd később kifejtem.Amúgy összességében jó irányban halad a dolog, de még sokat kell ezen dolgozni
-
#15482
mallee
tag
Speeedfire
#15462
mallee
tag
válasz
Speeedfire
#15462
üzenetére
addslashes? Semmi értelme, haszontalan.
-
mallee
tag
válasz
PumpkinSeed
#15444
üzenetére
Mit értesz biztonságos alatt? Amúgy bármilyen webről jövő adatot nem biztonságosnak kell tekinteni.
-
mallee
tag
válasz
DNReNTi
#15427
üzenetére
de ha ez az osztály nem a root-ban hanem egy almappában kerül meghívásra
Hirtelen ezek a megoldások jutottak eszembe erre:
1. Használj autoload-ot és a konfigurációs beállításokat egy osztályba tedd, pl Config_Database. Ez még mindig nem szép megoldás, de a problémát feloldja.
2. Biztos van valamilyen inicializáló, közös része az alkalmazásodnak, ahol be tudod olvasni a konfigurációt és be tudod állítani a Database_Connection statikus mezőit. Ehhez azonban a láthatóságot át kell állítanod. Ez már egy egészen jópofa megoldás kezd lenni, viszont ebben az esetben koncepcionálisan rossz a Database_Connection osztályod.
3. Van egy osztályod, ami a konfigurációt kezeli (beolvassa a megfelelő helyről) és tőle lekérdezi a Database_Connection osztály a megfelelő értékeket. Ez már szép megoldás is lehet, megvalósítástól függ.
4. Van valamilyen osztályod, amely a függőségeket kezeli, pl eltárolja a Database objektum referenciáját és ahol adatbázissal akarsz foglalkozni, ott ettől az osztálytól kérdezed le a Database objektum referenciáját. Ennek egy nagy hibája, hogy eléggé központosított lesz a kód, túlzottan erős lesz a szerepe ennek az osztálynak, minden tőle fog függeni.Úgy gondoltam egy osztály marad a lekérdezések kezelésére, csak több metódus lesz. Lesz egy private, ami ellenőrzi a lekérdezés helyességét, a paramétereket, stb, valamint query típusonként 1-1 metódus.
Ez elég szép megoldásnak hangzik
A többit már elmondták előttem, várjuk az új verziót
-
mallee
tag
válasz
fordfairlane
#15420
üzenetére
Helyesen az ilyen kreátor objektumoknak az általad felvázolt módon sem lenne szabadna létezniük, helyette minden objektum kívülről várná a függőségeinek "kielégítését": bővebben.
-
#15418
mallee
tag
csabyka666
#15417
mallee
tag
válasz
csabyka666
#15417
üzenetére
Érzésem szerint az index.php minden újratöltéskor lefut.
Ha mindig lefut, akkor elég ennek az egy fájlnak a tetején létrehozni a kapcsolatot.
-
mallee
tag
válasz
DNReNTi
#15412
üzenetére
Gondolatébresztők:
Database_Connection
private static $DB_Host = ........: Ennek a helye egy config fájlban lenne és valamilyen okosság mentén kéne beadni az osztályodnak.
error_reporting(0);: Miért kezel az adatbázis osztályod error reportolást? Mi köze van a kettőnek egymáshoz? (azon túl, hogy az adatbázis-kapcsolat felépítése esetén is jöhet hiba). Ennek inkább egy inicializáló, környezetet beállító, stb php-ben kellene lennie
echo 'Database connection failed. Code : ' . $DB_Connect->....; Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább, noha ő arra számított, hogy lesz adatbázis-hozzáférése. Ehelyett használj exception-t
Mi volt ezzel az osztállyal a célod? Hány helyen és hol hívod meg?
Database
Hát ez így nagyon nem jó. Több kisebb osztályba kéne szétvágni az executeSQL-t az SQL parancs típusok alapján, pl Database_Select_SQL valósítaná meg a selectes logikákat, Database_Insert_SQL az inserteset, stb. Ezzel elkerülhetnéd azt a csúnya és nehezen értelmezhető switch-case szerkezetet. Egyébként bár látom, hogy mi akar az osztály célja lenni, mégis nagyon rosszul olvasható a kód. A sok egymásba ágyazott if-else throw exception megoldás helyett inkább azt kéne vizsgálnod a feltételben, hogy sikertelen volt-e a végrehajtás: ha így van, akkor exception, egyébként fusson tovább a kód, pl:
$stmt = $this->_DB_Connect->prepare($SQL_command);
if ($stmt === false) { throw new Exception("blablabla"); }
$parameter_type_list = '';
foreach($SQL_parameters as $parameter) {
és nincs utána else!Ez sem tökéletes megoldás, de átláthatóbb a kevesebb egymásba ágyazott szerkezet miatt.
-
mallee
tag
válasz
mallee
#15405
üzenetére
A legjobb az egészben, hogy több egymásnak ellentmondó infót is találtam
Limitations
Please note that final, private and static methods cannot be stubbed or mocked. They are ignored by PHPUnit's test double functionality and retain their original behavior.Forrás: http://phpunit.de/manual/3.7/en/test-doubles.html
Úgy tűnik, hogy 3.5 alatt támogatott volt: http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Methods.html
Majd holnap megkapod 
A display_errors amúgy is legyen kikapcsolva, a hibákat nem kiíratni kell, hanem loggolni.
Új hozzászólás Aktív témák
- GYÖNYÖRŰ iPhone 12 mini 128GB Green -1 ÉV GARANCIA - Kártyafüggetlen, MS3395, 100% Akkumulátor
- Apple iPhone 16 Pro Max Natural Titanium Titán dizájn, Pro kamera,100% akku,2026. 02. 11
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7500F 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- iPhone 13 mini 128GB Green -1 ÉV GARANCIA -Kártyafüggetlen, MS3897, 100% Akkumulátor
- HIBÁTLAN iPhone 13 Pro Max 256GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3521, 100% Akksi
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest