Podstrony
- telcocafe
- [PHP+MySQL] Problem z połączeniem mysqli('localhost', 'xxx', 'xxx', 'xxx'
- [PHP] Wyrażenia regularne. Zamienić name="info_imie" na name="{info_imie}"
- [php] Dodanie textu do pliku. Problem... :) POMOCY!!!!!!!!!!!!!
- [PHP] Skrypt cenzury Chcę cenzury!!!
- Dobre programy do edycji php Dobre programy do edycji php
- [PHP] podział na strony php: podział na strony
- [PHP i MySQL] jak pobrac liczbe rezultatow Jak pobrac liczbe rezultatow???
- jak zrobic aktualizacje php? pomocy!!!!!
- Błąd w PHP-Fusion pomocy !!!!!
- Daczego nie dziala?? skrypt php nie chce działać!!!
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- szkoleniahr.opx.pl
telcocafe
Pewnemu skryptowi CMS przyjrzał się doświadczony programista. Postawił kilka zarzutów:1. Dlaczego strukturalnie?
2. Brak mechanizmów cache
3. Brak mod_rewrite
4. Użycie global, za co powinienem wychłostać się (to nie ta epoka)
1. Dlaczego strukturalnie?
Skrypt nie jest napisany w pełni obiektowo - podobnie jak PhpBB 3, PunBB, phpMyAdmin i cała rzesza CMS-ów. Dla każdego żądania tworzy obiekty do obsługi bazy danych (PDO) i szablonów (własna klasa Content). Napisałem też klasy do zapisu konfiguracji, wysyłania e-mail i PW, nadzoru nad zapisem pozycji, budowania RSS, kompilowania szablonów i instalacji systemu dla każdego języka. Mimo to architektura jest strukturalna.
Pozostaje pytanie: czy wszystko trzeba pisać obiektowo?
Pisząc obiektowo, można ułatwić tworzenie i modyfikowanie aplikacji lub całkowicie poplątać kod. To zależy od podejścia i dobrze zaplanowanej architektury.
Płatne skrypty forum vBulletin i IPB są napisane obiektowo.
1.1. Wydajność
Twórcy kodu strukturalnego twierdzą, że stawiają na wydajność. Tak samo twórcy kodu obiektowego. Dobrze napisany kod strukturalny lub strukturalno-obiektowy musi być szybszy od w pełni obiektowego. Ładowanie X klas, tworzenie obiektów, wywoływanie metod - to wszystko wpływa na czas i użycie pamięci. Styl programowania może nie ma największego wpływu na wydajność, więc przejdźmy dalej.
Do przeglądarki i tak serwer wysyła tylko kod HTML. Strony są składane w locie - to nie jest tak, jak w aplikacjach okienkowych lub skryptach JS. Tam jest pełna obiektówka nawet wskazana. Javascript jest w całości obiektowy.
2. Brak mechanizmów cache
Aktualnie stosuję cache dla najważniejszych komponentów, np. menu, lista najnowszych pozycji, hierarchia kategorii, menu w panelu admina... Ogólnie czasochłonne operacje są wykonywane tylko raz. Przykład: liczba pozycji w kategoriach jest zapisywana w bazie danych.
To za mało. Zarzucił, że skrypt za każdym razem wykonuje zapytania do bazy danych - bez żadnego cache. Weźmy przykład: wyświetl listę prywatnych wiadomości albo listę artykułów na stronie 2.
Bazy danych mają własny mechanizm cache. Czy to prawda, że wystarczy zmiana jednego warunku i wszystko leci od nowa? Czyt. gdy zmieni się fragment po komendzie WHERE - szczególnie w połączeniu z poleceniem JOIN.
Gdyby tak tworzyć cache wszystkich zapytań? Wtedy można ominąć w ogóle połączenie z bazą danych. Ogromny wzrost wydajności. Tylko to raczej nie zawsze jest możliwe, szczególnie gdy włączymy panel "osoby online" (przy dużym ruchu).
2.1. Przeznaczenie
Nikt nie będzie na takim skrypcie budował Naszej-Klasy albo Dziennika Internautów, który po padzie GG też miał problemy z wydajnością. Google na pierwszym miejscu wyświetlał news z tego serwisu. Później udostępnili lekką wersję.
CMS, który osiągnąłby najlepszą wydajność, generowałby po prostu strony .html. To jednak jest niemożliwe. Logowanie, dynamiczna zawartość, która zależy od preferencji.
Czy dodatkowe mechanizmy cache są więc potrzebne? Czy raczej powinno stosować się specjalne rozszerzenia do pamięci podręcznej?
3. Brak mod_rewrite
Na początku zamierzałem wprowadzić obsługę mod_rewrite. Zrezygnowałem z 1 powodu. Zbyt dużo kombinowania. Musiałbym zmienić sposób tworzenia linków, a wtedy straciłbym kompatybilność z wersją 2.1.
Obecnie: ?co=art&id=5&page=2
Krótki link: /art/5/2 albo /art/5/tytul-artykulu/2
Kilka reguł w .htaccess i można z powodzeniem wprowadzić krótkie URL-e, ale to dość toporny sposób. Dlaczego? Otóż skrypt musi obsługiwać także zwyczajne URL-e. Nie ma też uniwersalnych reguł dla wszystkich modułów. Nie - przy obecnej architekturze nie da się w pełni wprowadzić krótkich URL.
Tutaj znów wracam do przeznaczenia. Na większości darmowych hostingów krótkie URL-e są wyłączone. Sytuacja zmienia się na lepsze, ale np. na DHost wciąż nie ma obsługi mod_rewrite. Podobnie z subdomenami.
4. Słowo global
Bardzo krytykowane w środowisku OOP. Zazwyczaj zastępowane singletonem, choć nie widzę wielkiej różnicy (jedynie obiekty nie są dostępne w globalnym zasięgu, a tam żadna klasa nie ma nic do szukania). Singleton na pewno można zastąpić lepszym wzorcem.
Przy obecnej architekturze nie da się ominąć global. Podobnie w PhpBB 3 - ten deklaruje jeszcze więcej zmiennych globalnych w funkcjach.
Pewnemu skryptowi CMS przyjrzał się doświadczony programista. Postawił kilka zarzutów:
1. Dlaczego strukturalnie?
Bo jesteś fanem Erlanga
2. Brak mechanizmów cache
Nie robiłeś tego dla Naszej Klasy
3. Brak mod_rewrite
Nie chciałeś się irytować gdy na darmowych dno-hostingach nie będzie mod_rewrite.
4. Użycie global, za co powinienem wychłostać się (to nie ta epoka)
Ale to tak ładnie wygląda. Globalny, ogólnoświatowy projekt ^_^
Pozostaje pytanie: czy wszystko trzeba pisać obiektowo?
Napisz mu to w Ruby, Javie czy Pythonie, tam wszystko jest obiektem :)
Płatne skrypty forum vBulletin i IPB są napisane obiektowo.
Obiekt chaosu :)
To za mało. Zarzucił, że skrypt za każdym razem wykonuje zapytania do bazy danych - bez żadnego cache. Weźmy przykład: wyświetl listę prywatnych wiadomości albo listę artykułów na stronie 2.
Memcache jest fajny. Widziałeś go gdzieś na tanim/darmowym serwerze? A baza działająca w RAMie kontra kesz do plików txt = MySQL wins przy niedużych obciążeniach typowych dla zastosowań tego CMSa.
"Super" skrypty robi się inaczej niż te "masowe" działające na prostych hostingach ;)
Część profesjonalistów ma takie zboczenie, że nawet kiedy robi coś czego będzie używać 10 osób to zapakują frameworka, cache i bóg wie co jeszcze. Po fakcie projekt ma trzy strony widoczne dla użytkownika, pięć funkcji na krzyż i 15mb plików tekstowych z kodem :)
Trzeba wiedzieć co się robi i w jakim celu(chociaż global to akurat sobie mogłeś darować :P ).