Kai kas nors kuria programą, jam iš pradžių reikia pasirinkti kokia bus failų struktūra. Kaip jie tarpusavyje sąveikaus ir pan.

Taigi, šiame straipsnyje parodysiu kokios programos failų struktūros pačios geriausios.

Nedidelė Programėlė

Mažoms programoms kaip ir nereikia jokios failų struktūros. Bet galvokim apie ateitį. Gal reikės praplėsti tą programą, o gal kur nors integruoti. Šiam dalykui, manau, labiausiai tinka tokia struktūra:

Pagrindinė direktorija:
- index.
- DIR: engine
- DIR: design

Direktorija: engine
- main.
- hello.function.
- bye.class.
- .htaccess

Direktorija: design
- DIR: images
- style.css

index. - paprastas failas sukišti main. failo generuojama informaciją į dizainą.

main. - visas puslapio varikliukas.

.htaccess - Apache konfigūracijos failas neleidžiantis niekam užeiti į engine direktoriją.

*.class., *.function. - didesnes klases/funkcijas reikia skirstyti į atskirus failus. Galų gale ne visada jų gali prireikti.

.htaccess:
denay from all

Programa Milžinė

Didelės programos failų struktūra nelabai ir skiriasi nuo mažos, nebent tuo, kad viskas labiau suskirstyta į direktorijas. Bet su jomis nereikia per daug persistengti…

Pagrindinė direktorija:
- DIR: engine
- DIR: module
- DIR: themes
- index.
- post.
- get.

Direktorija: engine
- DIR: class
- DIR: function
- main.
- comments.
ir t.t.

Direktorija: module
- DIR: top_user
- DIR: hide_header
ir t.t.

Direktorija: themes
- DIR: dark_php
- DIR: kubric
ir t.t.

index. - tas pats veikimo principas kaip ir mažoje programoje.

post. - maža duomenų priėmimo ir apdorojimo programa. Šis failas gauna duomenis POST metodu ir siunčia juos ten kur reikia.

get. - tas pats kaip ir post., tik ši programa priima duomenis GET metodu.

Module direktorijoje yra sukrauti visi moduliai. Reikia turėti omeny, kad kiekvienas modulis gali turėti savo CSS failą arba kokį paveiksliuką, tai į tą direktoriją nėra dedama htaccess.

Kaip pastebėjote klasės ir funkcijos turi savo direktorijas. Jeigu yra daug įvairių funkcijų/klasių, kyla problemos jas surasti. O kai naudojama tokia struktūra, nereikia failams naudoti prierašų class/function.

Tokias klases ir failus dažniausiai nelabai patogu įkelti į modulį ir pan. Aš tam naudoju specialią funkciją.

Funkcijos naudojimas labai paprastas:
use(”form_check.c, replace.f, pixel”)

Iš pradžių nurodomas klasės/funkcijos pavadinimas, o paskui nurodoma ar tai klasė, ar funkcija.
c - klasė
f - funkcija
Jei nenurodyta, automatiškai parenkama funkcija.

Tai tiek. Dėkui, kad skaitėte.

Ernestas Stankevičius (a.k.a Bad.F.Word). Apie autorių.

Panašūs straipsniai


“PHP Programos Struktūra” komentarų: 14

  1. Emilis

    Na… dar vienas lapelis nuo rulonėlio… O tikėjausi surasti bent kokių minčių.

    - Paprastai ne po vieną funkciją būna faile, tai “.function.php” nelogiškas.
    - Kam reikalingi get.php ir post.php taip ir nesupratau… Neužtenka $_REQUEST? Arba tikrinimo kontroleryje, jei jau esate pedantiški?
    - Ką comments.php veikia engine direktorijoje ir kodėl tai vienas php failas, o ne modulis?
    - “hide_header” kvepia overengineering’u. Jei reikia rašyti kodą, kad kažko _nerodytų_, tai jums tikriausiai reikia pergalvoti savo sistemos struktūrą
    - Kur dėti trečios šalies bibliotekas tokias kaip ADOdb arba Smarty?
    - Kodėl “themes” daugiskaita, bet “module” vienaskaita?
    - PasteBin kode klaidos: nėra apibrėžta MAIN_DIR; funkcijas require’ina iš klasių direktorijos
    - kodo gabalų pagrindinis rūšiavimas į klases ir funkcijas — neracionalus. Visų pirma nereikia prisidaryti per daug failų. Tam geriau kuo labiau išskirstyti funkcionalumą į modulius. Iš bėdos dar tiktų ir skaidymas pagal MVC.

    “Jeigu yra daug įvairių funkcijų/klasių, kyla problemos jas surasti.” apie ką ir šneka… prikuriat belenko ir paskiau patys nerandat :-)

    Jau geriau būtumėte nuo Rails’ų struktūrą pavogę ir pavaidinę, kad patys išmastėt — kas nors neišsilavinęs perskaitęs gautų daugiau naudos, nei iš tokių “struktūrų”.

  2. KIK

    Šis variantas geresnis už mano naudojamą :) Ateityje stengisiuosi šitaip ir daryt :) O dabar naudoju tokį kokį naudoja kai kurios populiarios CMS plius kai ką pasikeitęs.

  3. shazo

    Ojėj. Jau tikrai geriau reikėjo iš ko nors pavogti, būtų buvę daug naudingiau.

    Nepedrąsiai čia pareiškei su pačiomis geriausiomis struktūromis? Beje, kur kitos, nes tik vieną įžvelgiau? :/
    Įdomu kuo tas gerumas pasireiškia, nors mano subjektyvia nuomone yra daugybė patogesnių struktūrų, o dėl jų gerumo nežinau. Naudoja kiekvienas kas jam patinka.

    Ir ar ne per skambu vadinti PHP skriptus programomis?

  4. Žilvinas

    Kažkoks vaikiškas straipsnis. Kiek pastebėjau dauguma straipsnių pixel.lt yra tokie. Hellooooo, pasaulyje yra ir advanced programuotojų, tad jeigu norite sudominti platesnį ratą žmonių ir suformuoti bendruomenę, tai gal paruoškit ir kokybiškesnių straipsnių?

  5. Raimundas Zabarauskas

    Vertingas tekstas. Ne, tikrai, aš nuoširdžiai – labai pralinksmino iki ašarų.


  6. Visiškai sutinku su Emiliu - strukture na kokia.
    Asmeniškai nepatiko tai kad:
    Mazam projekte css ir paveisliukai iškelti į atskirą kataloga, kas nera patogu ir didina HTML kodo didį (nors čia yra dirbančios komandos susitarimo reikalas).
    Funkcijas visada apjungia į bibliotekas pagal jų paskirtį - kas sutaupis laiko ir kuriant ir resursus naudojant skriptą (kiekvienai funkcijai atskiras include - čia gi kiek nuskaitmu reikia padariti).

    Asmeniškai naudoju kratini nuo Rails strukturos, kažkas panašaus yra ir pas Zend Framework. Aš iš vis neisivaizduojų didelio projekto kurimo be MVC modelio, įpač jai dirbama komanda.

  7. asterisk

    Žilvinai, turėčiau pastebėti, jog straipsnius ruošia ne konkrečiai Pixel.lt, o žmonės, kurie nori pareikšti savo nuomonę. Tad jeigu turi kažkokių geresnių minčių ar advanced lygio straipsnių - pasidalink ;) O bendruomenė formuojasi būtent dėl to, jog bet kas gali pasireikšti. Na žinoma, tam tikri kokybės reikalavimai yra, ir galiu pasakyti kad ne visi straipsniai būna publikuojami.

    PHP skriptų struktūra yra labai ginčytinas dalykas, tiesa Bad.F.Word pasiūlytas variantas tikrai yra “skylėtas”.

  8. Shar

    Tai būtų labai malonu, jeigu kasnors parašytų normalų straipsnį šia tema. Man pačiam šiuo metu yra aktualu kokia programos struktūra naudoti, ir nelabai kur randu pavyzdžių….

  9. Žilvinas

    Visai nebloga struktura yra emilio frameworke ctlf. aisku jis ji jau nustojes developint kiek supratau, bet adresas is kur parsisiusti yra ctlf.sf.net . Naudoju ta frameworka, tik esu ivedes siokiu tokiu pakeitimu, kurie labai palengvina ir pagreitina darba. Tiek kategoriju strukturoj, tiek engine’e.

  10. Rimantas

    Uh, oh. Kaip kad nelietuviai sako, “this is wrong on oh so many levels…”.
    Negi taip sunku patestuoti kodą dedamą į straipsnius?
    1) “denay” apache, ko gero, nesupras. Nebent “deny”.
    Bet čia dar niekai.

    2) Funkcija kurią “naudoji”. Papasakok man, kaip ji gali veikti? Kodėl klausiu:
    a) “use” PHP yra rezervuotas žodis, taigi savo funkcijos taip pavadinti nepavyks.
    b) Čia didysis perlas:
    @require_once(MAIN_DIR.”class/”.$item[0].”.php”) OR die(”Klasė ‘”.$item[0].”‘ neegzistuoja.”);

    OMGWTFLOLGTHFAST?
    Tas kodas iš principo veikti negali, nes:
    i) require_once, jei negali užkrauti reikalaujamo failo išmetą warning’ą ir numiršta (fatal error). Programa OR net nepasiektų, tuo labiau die();

    ii) jei failas egzistuoja, tai su OR prasideda įdomiausias cirkas.

    require_once(”file.php”) or die(”msg”) yra tapatu (require_once nėra funkcija ir skliausteliai nereikalingi) tokiam užrašymui: require_once “file.php” or die(”msg”). PHP prmiausia bando susigrabalioti, kas gausis su šituo: “file.php” OR die(”msg”);

    Eilutė “file.php” boolean kontekste yra TRUE, kas ir perduodama į require_once - kas eina po OR net nežiūrima. require_once bando pasiversti TRUE i failo pavadinimą, gauna “1″ ir bando užkrauti failą “1″. Trumpiau tariant, pastebine esanti funkcija visais atvejais bando krauti failą “1″, ir aišku, labai garsiai pergyventų jo neradusi, bet užtildyta su “@” tiesiog tyliai numiršta.

    Dėl to ir sakau, kad veikti negali iš principo.
    Pataisykit, jei klystu.

  11. Emilis

    Žilvinai> nebaigęs developinti. Tiesiog dėl to, kad iš darbo neprieinu prie SVN tai labai sunku surasti laiko atnaujinimus sukelti :-).

  12. Armandas

    Na gal nuo šiol redaktoriai pradės kažkiek griežčiau vertinti turinį ;)

  13. Dummas

    Tikėjausi kažko daugiau…

  14. Kuriam savo TVS » Pixel.lt

    […] kuriam savo TVS. Nuo ko turėtume pradėti? Gal nuo failų struktūros. Šia tema Pixel.lt buvo vienas straipsnis, tačiau labai sukritikuotas. Todėl, matyt, reikėtų pradėti nuo pradžių. Greičiausiai CSS […]

Rašyti komentarą

Jūs privalote prisijungti jeigu norite rašyti komentarą.