Symfony 2 Opcje

[paxton]

Symfony zaprezentowała nową odsłonę swojego projektu www.symfony.com pod którą już nie długo znajdziemy najnowszą wersja tego potężnego frameworka oznakowaną numerem 2.0.

Framework w dużym stopniu został przebudowany, i kod z poprzednich wersji nie będzie służył nam na najnowszej. Całą listę zmianek znajdziemy na oficjalnej stronie, a dokladnie pod tym adresem: (Click).

Nowa wersja symfony będzie oznaczać ponowną naukę dla wielu osób. Framework działa inaczej niż jej poprzednia wersja. Całość jest napisana używając "pakietów" (ang. Bundles), np. Autoryzacje, ORM jak i sam w sobie framework. Nowa strona jest o wiele przyjemniejsza dla oka i na pewno zachęci do dołączenia już do dużej społeczności symfony. Symfony 1 stronę nadal możemy znaleźć pod starym adresem. (Click).

[Zyx]

Ja to mam tylko nadzieję, że przy okazji wersji 2.0 wezmą się wreszcie za zrobienie sensownej, jednolitej dokumentacji, bo to co jest do SF 1.x zrobione, to się średnio nadaje do poważniejszego użycia. I bardziej by mnie to ucieszyło, a nie nowa szata graficzna.

Ad. Symfony 2, to warto się z nim zapoznać. Jak Symfony 1.x za całokształt nie lubiłem, nie lubię i nie polubię, to w dwójce faktycznie wyciągnięto wnioski z błędów jedynki. Tylko właśnie żeby dokumentacja była sensowna do tych wszystkich rzeczy...

Jedynie nieco ostrzegam przed zbyt pochopnym używaniem Doctrine 2 ORM w swoich projektach. Bawię się nim już od maja 2010 i o ile faktycznie jest on dużo lżejszy, a DQL wreszcie ma szansę działać poprawnie przy bardziej skomplikowanych zapytaniach, to:

- Współpraca z bazami danych innymi niż MySQL dalej wygląda średnio. Zwłaszcza boli to w odniesieniu do PostgreSQL-a, gdzie w zasadzie z powodu Doctrine'a tracimy prawie wszystkie przewagi PgSQL nad MySQL-em, a jakość kodu odpowiedzialnego za współpracę z tą bazą danych jest dużo niższa.
- W "dwójce" jest więcej ograniczeń co do struktury schematu. Do typowego projektu stronki WWW w zupełności to wystarczy, ale przy czymś bardziej skomplikowanym może okazać się, że część projektu będzie trzeba przepisać z ich powodu; ja już jeden projekt musiałem z D2 na czysty SQL przepisać...
* Nie można definiować domyślnych wartości pól.
* Brak obsługi typu BLOB. W PostgreSQL-u oznacza to, że praktycznie nie ma możliwości przechowywania w bazie jakichkolwiek danych binarnych czy danych w kodowaniu innym, niż to wybrane dla naszej bazy danych.
- Przy bardzo skomplikowanych schematach trzeba napisać (i wykorzystywać) mnóstwo całkowicie niepotrzebnych z punktu widzenia zasad projektowania obiektowego obiektów tylko po to, by w bazie znalazły się odpowiednie tabele.

Symfony 2 nie testowałem jeszcze pod kątem tego, jak sprawdza się z wyrzuconym ORM-em, ale wnioskując po mechaniźmie "bundles" śmiem przypuszczać, że jest to rozwiązane także lepiej, niż w jedynce.

Ten post edytował Zyx 8.03.2011, 08:25:16

[paxton]

Również mam ogromna nadzieje ze zrobią coś z dokumentacją, to była porażka dotychczas.

[Cysiaczek]

Pomijając\Zasmiecenie\Kodu i konieczność 'Uzywania\Pełnej\Ścieżki\Do\Encji\W\Apostrofach' w Doctrine 2 (nie upieram się, ale ja tak musiałem robić i nie udało mi się inaczej), to sam FW rozwiązali bardzo przyjemnie. Piszesz sobie klasy Modelu, robisz im referencje do innych obiektów na polach, dodajesz reguły walidacji i można to wrzucić w domyślny Validator, który obada Model. Jak dodamy znaczniki @Entity, to nam Doctrine pięknie tabele porobi. Generalnie jest spoko, ale dokumentacja jest
a ) najczęściej niezgodna ze stanem faktycznym
b ) niekompletna

Co do DQL Doctrinowego, nie mam pochlebnego zdania ze względu na nadmierną komplikację. Bardziej podoba mi się trzeźwe spojrzenie Francois Zaninotto na konieczność używania funkcji ORMowych
http://propel.posterous.com/how-can-i-writ...ry-using-an-orm

Powód edycji: [Cysiaczek]:

[Crozin]

Co do Doctrine - niby z samym FW nie ma nic wspólnego, ale w praktyce to właśnie ten projekt jest faworyzowany:
1. Rzeczywiście podejście wspieramy tylko i wyłącznie to co jest obsługiwane przez wszystkie RDBMS-y jest wg mnie chore i projekt na tym sporo traci.
2. Tworzenie nowych typów czy konstrukcji DQL aż takie trudne nie jest, więc zawsze można sobie dopisać obsługę nieco mniej popularnych rzeczy - jednak mimo wszystko sam Doctrine powinien oferować więcej. Brak obsługi dziesiątek prostych elementów, których implementacja pochłonęła by pewnie raptem parę dni strasznie razi.

najczęściej niezgodna ze stanem faktycznym

Dokumentacja na stronie Symfony odnosi się do ostatnio wydanego PR-a, ale jest dostępna również jej najnowsza wersja, która w miarę poprawnie pokrywa nowowprowadzane dane.

[Zyx]

Cysiaczek -> ja po prostu tworzyłem dla modeli przestrzenie nazw głównego poziomu i podpinałem je do ładowarki klas osobno .

Crozin -> wiem, że można, ale co z tego, kiedy taka implementacja typu bytea z PostgreSQL, która teoretycznie zwraca Doctrine'owi dokładnie takie dane, jakie powinna, zwyczajnie nie działa?

[Crozin]

Z Doctrine2 pracowałem wyłącznie z MySQL-em, tak więc na słowo przyjmuję, że rzeczywiście nie działa.

[cojack]

- W "dwójce" jest więcej ograniczeń co do struktury schematu. Do typowego projektu stronki WWW w zupełności to wystarczy, ale przy czymś bardziej skomplikowanym może okazać się, że część projektu będzie trzeba przepisać z ich powodu; ja już jeden projekt musiałem z D2 na czysty SQL przepisać...

Jest coś takiego jak createQuery w Doctrine, i nie musisz przepisywać tego co już masz na zwykłego sql'a... No ale.

A jak nie potrafisz escepować bytea, to sobie zapisz to do base64 i święto lasu a kolumnę w bazie utwórz jako TEXT, zresztą pomysł z trzymaniem w bazie bytea, nigdy go nie polecałem, nie będę polecał... ale czasami nie ma prostszego wyjścia ;/