Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Architektura projektów PHP, techniki, modele itd.
Forum PHP.pl > Forum > PHP
griszasm
Witam !
Wybór odpowiedniej architektury projektu często zależy od późniejszej szybkości jego ulepszania/wprowadzania zmian, unowocześniania itd. Pytanie tylko jak zaprojektować odpowiednią architekturę i rozwiązać podstawowe problemy takie jak:

1) System plików i katalogów - tzn jaką należy zaproponować strukturę katalogów ? Katalog główny aplikacji, gdzie trzymać piki JS, CSS, HTML i inne ? Czy dobrym rozwiązaniem jest wyodrębnienie katalogu src, w którym znajdować się będą poszczególne katalogi zawierające pliki JS, CSS, HTML itd. Jak oddzielić od siebie poszczególne aspekty projektu ? Czyli kod html od kodu php, odrębną sekcję obsługującą ajaxy itd itp ... czyli ogólnie - struktura katalogowa i co gdzie trzymać ?

2) Podział na moduły - tzn jak podzielić odpowiednie części projektowanego portalu ? Przykładowo mamy jakiś system, a w nim panel użytkownika i zakładki na których są sekcje rownież podzielone na zakładki ... i na jednej z zakładek mamy formularz, który też jest podzielony na sekcje smile.gif Gdyby to wszystko miało być w jednym pliku to mamy dobre kilkadziesiąt instrukcji if [i to jeszcze zagnieżdżonych], które są ciężkie w utrzymaniu. Również instrukcja "require" [bo tak do rej pory robiłem] jest chyba nie zalecana ? Co o niej sądzicie ?

3) Zarządzanie danymi - tzn gdzie trzymać dane wpisywane przez użytkownika i w jaki prosty sposób zarządzać nimi i zależnościami pomiędzy nimi [może pliki XML ?]. Przykładowo, użytkownik wpisuje na pierwszej zakładce jakąś wartość od której zależy układ następnych zakładek (przykładowo na pierwszej zakładce są dane ogólne klienta gdzie wybieramy "nowy klient sklepu" lub "klient sklepu od XX miesięcy" -> jeśli wybierzemy klient sklepu od XX miesięcy, na drugiej zakładce zestaw danych będzie inny). Jak tym łatwo zarządzać i gdzie przechowywać dane, które aktualnie user wypełnia [bo przecież nie w sesji ? to potworne marnotradztwo]. Słyszałem o takim pojęciu jak PostBack, gdzie dane bodajże są wysyłane Ajaxem, sprawdzana jest ich poprawność w czasie rzeczywistym i cały czas jest zachowany STAN aplikacji. Czyli kolejne pytanie - co gdzie i jak ?

4) Wzorce projektowe i frameworki - słyszałem o MVC ale nie mam pojęcia z czym to się je ? Próbowałem instalować Symfony ale podczas generowania projektu z konsoli "symfony generate:project nazwa_projektu" otrzymuje komunikat "A project named nazwa_projektu already exists in this directory.". Nie mam pojęcia za co się zabrać i jak ?

5) Elegancki i przejrzysty kod - tu jest temat morze smile.gif Jakich standardów użyć ? ile kodu w jednym pliku i jak ułożone ? Czy lepiej użyć PHP4 czy PHP obiektowego ? Mieszanie kodu PHP z HTML [kiedyś robiłem tak że np mam formularz a w nim etykiete i pole, pod polem natomiast było coś takiego <?php if($err=="DateError") print "Błędna data"; ?> co oczywiście oznaczało komunikat o błędnie wprowadzonej dacie. Plik HTML musiał więc zawierać kod PHP sad.gif w action formularza oczywiście był plik PHP, który zajmował się przetwarzaniem ale w przypadku błędu i tak używałem header("Location: $addr?err=DateError");, jest to pewnie zła praktyka ?] Kolejny problem - jak nazywać zmienne, funkcje i pliki ?

6) Właściwe korzystanie z dobrodziejstw - czyli kiedy używać sesje a kiedy nie ? Jakich rozwiązań się wytrzegać ? Co najbardziej spowalnia działanie ? Jakiego rodzaju instrukcji starać się unikać ? W jakim środowisku najlepiej to robić [może Eclipse] ? Czy tworzenie bazy i uzupełnienie jej przykładowymi danymi pozostawić w plikach sql ? Do tej pory robiłem to ręcznie w PHPMyAdmin. Czy korzystać z Subversion [Np tortoise lub subclipse do eclipsa] ? Te i inne problemy opiszcie prosze tutaj.

Pozdrawiam

Domin
Quider
poruszazs takie tematy, na ktore na tak na prawde sam sobie mozesz odpowiedziec. Wszytko jest kwestia gustu, o którym sie nie dyskutuje. Zawsze mozesz doczytac kilka poradnikow aby rozjasnic sobie pole manewru.

Ja zabierajac sie za projekt CMS najpierw prestudiowalem wszystko co znalazlem w internecie na temat frameeworkow, cms, itp tongue.gif potem wziolem sie za pisaanie
.radex
szczerze? zainteresuj się jakimiś frameworkami. Nie tyle, żeby na nich coś stworzyć, tylko, żeby nabrać dobrych nawyków i poznać różne techniki. A o MVC jest tyle w necie (i na php.pl), że sobie znajdziesz.
plurr
Myślisz w dobrym kierunku, nawet znalazłeś pełną odpowiedź - Twoje problemy rozwiązuje MVC, najlepiej zacznij od jakiegoś frameworka - narzuci Ci styl. Jeśli symfony jest dla Ciebie za trudne, to może zobacz inny. Prócz symfony i zenda nie masz większego wyboru. Zend jest łatwy w instalacji, zobacz go.

3) wypełnione już dane to trzymiesz w bazie, a nie w plikach. Chyba że czegoś nie skumałem?

5) tylko i wyłącznie obiektówka, strukturalnie to możesz pisać proste skrypciki np pod crona. Ucz się MVC, reszta wozrców sama się przypałęta. Wcześniej jednak musisz potrafić pisać obiektowo. Z reguły nie mieszamy kodu php z html, do tego są różne systemy szablonów albo alternatywna skladnia php.
griszasm
Cytat(plurr @ 2.04.2009, 08:22:21 ) *
3) wypełnione już dane to trzymiesz w bazie, a nie w plikach. Chyba że czegoś nie skumałem?


Chodzi mi o dane, które trzeba trzymać w formularzu zanim trafią do bazy (aby np przy błędzie lub odświeżeniu user nie musiał za każdym razem tego wpisywać) ... trzeba je jakoś tymczasowo zapisywać bo równie dobrze mogą trafić do bazy (jeśli wszystko Ok i są poprawne) lub użytkownik odświeży przeglądarkę i wtedy utraci dane, które wpisał. Co sądzicie o Ajaxie ? Tzn dokładnie sprawdzanie danych formularza Ajaxem vs. JavaScriptem ?
erix
Cytat
Tzn dokładnie sprawdzanie danych formularza Ajaxem vs. JavaScriptem ?

Była dyskusja na ten temat. Powinny być oba sprawdzania - AJAX: np. czy login jest zajęty, czysty JS: poprawność składni.

Cytat
trzeba je jakoś tymczasowo zapisywać bo równie dobrze mogą trafić do bazy (jeśli wszystko Ok i są poprawne) lub użytkownik odświeży przeglądarkę i wtedy utraci dane

A od czego masz sesje?
griszasm
Cytat(erix @ 2.04.2009, 12:09:58 ) *
A od czego masz sesje?


Wiadomo w sesji można to trzymać ale np trzymanie dużej ilości danych to raczej jej zawalanie. Pozatym gdy user odświeży przeglądarkę dane które zostały przez niego już wprowadzone znikną. Można by je zapamiętywać w sesji gdy zostaną zwalidowane ... ale jak to zrobić JavaScriptem ?

Mam jeszcze jedno pytania: Gdzie trzymać zapytania SQL ? w jednej klasie udostępniającej metody wykonujące operacje na bazie ? Np getAllUsers(){} - zwraca userów ... ? Pozatym przykładowe zapytanie:

select * from users where name='$username' AND pswd='$userpswd'; ... jest z tego co słyszałem błędne ponieważ lepiej jest używać "bindowania zmiennych" - czyli kolejny temat. Z czym to się je ? Może jakieś przykłady [bardzo uproszczone/prowizorka]
zzeus
Jak chodzi o zapytania SQL i ich trzymanie w jednym miejscu zainteresuj się wzorcem fabryki (jak się nie mylę) smile.gif
Natomiast bindowanie polega na dynamicznym podpinaniu wartości do zapytania SQL. W ten sposób wysyłasz raz szkielet zapytania do bazy danych a później np. w pętli wysyłasz dane potrzebne do jego wykonania. Poza tym że skraca to czas wykonania to jest bezpieczniejsze bo odporne na ataki typu SQLInjection, ponieważ baza danych sama kontroluje typ danych jakie powinna dostać.
Więcej na temat bindowania -> Biblioteka PDO
erix
Cytat
Wiadomo w sesji można to trzymać ale np trzymanie dużej ilości danych to raczej jej zawalanie.

Czy ja wiem; zależy od formularza. Ale np. 20 KiB zserializowanych danych sesji, to nie jest dużo.

Cytat
Pozatym gdy user odświeży przeglądarkę dane które zostały przez niego już wprowadzone znikną. Można by je zapamiętywać w sesji gdy zostaną zwalidowane ... ale jak to zrobić JavaScriptem ?

Przekazujesz token żądania w GET.

Cytat
Mam jeszcze jedno pytania: Gdzie trzymać zapytania SQL ? w jednej klasie udostępniającej metody wykonujące operacje na bazie ? Np getAllUsers(){} - zwraca userów ... ?

Zainteresuj się modelem z MVC.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.