Forum PHP.pl

SF2 jest o wiele przyjaźniejszy dla Rapid Developmentu.

Przy ZF2 dostajesz pewien zbiór komponentów, z których tak na prawdę sam musisz ulepić coś fajnego więc w efekcie wejście w ZF2 trwa dłużej - samemu trzeba opracować pewne 'standardy' itp.

Przy SF2 dostajesz od razu całość gotową do szybkiego developingu.

Średnie czasy Requestów dla tych 2óch frameworków przy podobnie zaprojektowanej aplikacji (tak samo wykorzystany cache itp) będą porównywalne. A to, że Zend jest wydajniejszy jest mitem. Sami developerzy Zf żalili się na temat niskiej wydajności Zf1.
(http://forum.php.pl/index.php?s=&showtopic=204816&view=findpost&p=1005857)

Co do ORMa:

Nie wyobrażam sobie CRMa bez użycia ORMa ;-)
Obsługa kodu bazującego na masie tablic asocjacyjnych w aplikacji bazującej na pewnych bytach biznesowych będzie strasznie kosztowna. Sam taki kod prawdopodobnie w końcu 'osiągnie' bardzo niską jakość, ciężko nad nim będzie zapanować.
Wykorzystanie obiektów przy tego typu aplikacjach jest moim zdaniem niezbędne.

Praktyka jest taka, że gdy w jednym requeście wykorzystujesz niewiele rekordów (lub po prostu jeden ;]) to stosujesz ORM. Prawdopodobnie na tej jednej encji będziesz chciał wykonywać pewne skomplikowane operacje, które o wiele łatwiej wykonać w świecie obiektowym.

Jednak gdy masz jakieś listingi rekordów, bez zbędnych operacji na nich/logiki --> wykorzystujesz tablice asocjacyjne.

Dlaczego SF2 się lepiej sprawdzi?
Jest lepiej przystosowany do ORMa, obiektów itp. Głównie ze względu na formularze, które były w założeniu tworzone na potrzeby obiektów (Oczywiście mogą również obsługiwać tablice asocjacyjne, ale raczej tego się nie stosuje, chyba że do prostych struktur)

Poza tym nie wyobrażam sobie definiowania reguł walidacji dla tablic asocjacyjnych. Tak masz całą logikę zdefiniowaną za pomocą adnotacji w konkretnej klasie modelu, lub za pomocą jakiegoś XMLa/YAMLa (czegokolwiek).

A jak byś użył walidacji przy tablicach? Zapisywałbyś pewnie reguły walidacji przy formularzu co jest mało rozsądne.

Obiektami lepiej potem operować gdy będzisez tworzył API swojego serwisu. Do SF2 powstały pewne świetne biblioteki, służące do de/serializacji obiektów do JSON, XML, itp.

Więc tworzenie webservice'ów, RESTa itp będzie bardzo proste przy tak utrzymanym kodzie.


A jeśli chciałbyś zapytać o średnie czasy odpowiedzi to mogę tylko odpowiedzieć, że licz się z między 80ms - 600ms - 600 przy np obsłudze bardzo złożonych formularzy.

Takie testy na "hello world" są bezsensu - nic nie pokazują, a przewaznie są robione na MacBookach autorów Poza tym czy zauwazyłeś w komentarzach, że gość testował Symfony2 w środowisku DEV?

Taki sneak-peak:
Już wkrótce wrzucimy na bloga miarodajne testy porównujące Symfony2, ZF2, Silex, Node.js na podstawie prawdziwej aplikacji o realnym, specyficznym, zastosowaniu (a nie hello world).
Co jeszcze mogę zdradzić: testy będą robione na odpowiednio zoptymalizowanej pod taką aplikację, największej instancji serwera Amazon EC2 (a dokladniej to na dwóch takich instancjach) :-)

Osadzanie kontrolerów w templatce dobra rzecz Mi osobiście najbardziej podoba się automatyczne pobranie encji w akcji na przykład:

[PHP] pobierz, plaintext 
 
public function deleteAction( \My\BundleName\Entity\News $news){
 
}
 
[PHP] pobierz, plaintext 

zawsze to kilka linijek kodu mniej.