![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 155 Pomógł: 1 Dołączył: 12.12.2010 Ostrzeżenie: (0%) ![]() ![]() |
Witam,
Z racji rozwoju frameworków czas się przeżucić na coś nowego. Pisałem w CI, Kohana, Symfony 1, teraz Zend 1 od 1,5 roku. Myślałem o Zend 2 ale to całkowicie inna struktura niż Zend 1. Postawiłem ostatnio projekcik zbudowałem sobie nowe moduły ale to inna bajka niż Zend 1. Wszystko trzeba na nowo opanować. I teraz pytanie, czy jest sens brać się za ZF2 czy nie lepiej czasem przerzucić się na Symfony 2. Pewno jest tutaj kilka osób co pisze na codzien w SF2. Jak wydajność i nauka SF2? Chcę postawić nowego CMS i taki dosyć spory CRM. Czy w SF2 występje coś do generowania CRUD (jak było w admin generator w SF1?). Proszę o info. Ten post edytował basso 18.11.2012, 23:01:27 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 435 Pomógł: 40 Dołączył: 16.02.2003 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
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. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 11.10.2025 - 09:34 |