Hirdetés

Új hozzászólás Aktív témák

  • DNReNTi

    őstag

    válasz mallee #15416 üzenetére

    Szia,

    Köszi az észrevételeket! :R
    "Ennek a helye egy config fájlban lenne és valamilyen okosság mentén kéne beadni az osztályodnak."
    Igen, így is volt, de ha ez az osztály nem a root-ban hanem egy almappában kerül meghívásra akkor sajnos elhasalt, mivel nem találta a config file-t a megadott helyen. Abszolút hivatkozással működik de azt csúnyának ítéltem meg, így egyelőre maradt ez a megoldás.
    Erre mi lenne a legszebb, legjobb eljárás?

    "Miért kezel az adatbázis osztályod error reportolást?"
    Nem kezel. Az adatbázis kapcsolat létrehozása előtt ki aztán pedig bekapcsolja az error_reporting-ot, hogy hiba esetén egy szépen megformázott hiba oldalra tudja dobni a felhasználót (header()). Ha nem kapcsolnám ki, akkor maga a php dobna hibát, ami után nem menne a header, ezért van benne. Ez ebből hiányzik, mivel: 1: nincs hibaoldal, 2: teszt.

    "Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább"
    Az előzőben benne a válasz. Élesben egy hibaoldalra dob.

    "Mi volt ezzel az osztállyal a célod? Hány helyen és hol hívod meg?"
    Ez az osztály, pontosabban ennek az egy szem statikus metódosa egy mysqli objektumot ad vissza. Meghívásra egyszer kerül, a Database osztály konstruktora példányosítja saját maga számára.

    "Több kisebb osztályba kéne szétvágni az executeSQL-t az SQL parancs típusok alapján"
    Ebben teljesen egyet értek, és így is lesz. Illetve majdnem. Ú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.

    Összességében jól értem, hogy főleg szépséghibák vannak, de a működés, és az elképzelés életképes?
    Ha lesz időm ma update-elem, és jövök megint. :D

Új hozzászólás Aktív témák