Została wydana stabilna wersja frameworka Ouzo. Zapraszamy do wypróbowania na http://ouzoframework.org i zgłaszania ewentualnych uwag.

Podstawowe pytanie: dlaczego miałbym wybrać tego FW zamiast innego, tj. co go wyróżnia spośród innych.

ORM:
http://symfony.com/doc/current/book/doctrine.html

[PHP] pobierz, plaintext 
$product = new Product();
$product->setName('A Foo Bar');
$product->setPrice('19.99');
$product->setDescription('Lorem ipsum dolor');
 
$em = $this->getDoctrine()->getManager();
$em->persist($product);
$em->flush();
[PHP] pobierz, plaintext 

Ekwiwalent w Ouzo:

https://github.com/letsdrink/ouzo/wiki/ORM

[PHP] pobierz, plaintext 
$product = Product::create(['name' => 'A Foo Bar', 'price' => '19.99', 'description' => 'Lorem ipsum dolor']);
[PHP] pobierz, plaintext 

lub

[PHP] pobierz, plaintext 
$product = new Product();
$product->name = 'A Foo Bar';
$product->price = '19.99';
$product->description = 'Lorem ipsum dolor';
$product->insert();
[PHP] pobierz, plaintext 

lub

[PHP] pobierz, plaintext 
$product = new Produc(['name' => 'A Foo Bar', 'price' => '19.99', 'description' => 'Lorem ipsum dolor']);
$product->insert();
[PHP] pobierz, plaintext 

-------------------

Doctrine:

[PHP] pobierz, plaintext 
$repository = $this->getDoctrine()
    ->getRepository('AcmeStoreBundle:Product');
 
$query = $repository->createQueryBuilder('p')
    ->where('p.price = :price')
    ->setParameter('price', '19.99')
    ->orderBy('p.price', 'ASC')
    ->getQuery();
 
$products = $query->getResult();
[PHP] pobierz, plaintext 

Ouzo:

[PHP] pobierz, plaintext 
$products = Product::where(['price' => '19.99'])->order('price ASC')->fetchAll();
[PHP] pobierz, plaintext 

Ouzo implementuje wzorzec ActiveRecord.

Ouzo ma wbudowaną obsługę migracji schematu bazy danych.

Posiada bardzo dobre zaplecze do rozwijania aplikacji w oparciu o TDD/BDD (https://github.com/letsdrink/ouzo/wiki/Tests).

Garażowy framework jakich 34535353534534.

Ciężko mi się zgodzić z tą "konstruktywną" krytyką.

Framework mający ponad 800 commitów, ponad 13 000 linii kodu, 5 contributorów, w 85% pokryty testami i używany aktualnie produkcyjnie u kilkudziesięciu klientów można nazwać garażowym.

//EDIT
Stats: http://www.ohloh.net/p/ouzo

A co wyróżnia laravela po za wielkim szumem?


@piotrooo89 - to ma być alternatywa dla CI czy Symfony? Do kogo kierujesz to narzędzie?

5 contributorów? Wow... Tworząc projekt komercyjny w jakimś frameworku trzeba założyć, że może potrwać XX lat, nawet jeśli specka mówi inaczej. Nie chcę mi się rozpisywać, wystarczy zapoznać się z pojęciami dług technologiczny i okres wsparcia, dziękuję dobranoc.

CI osobiście nie wiem jak wygląda. Niemniej dla Symfony i jego ociężałego ORM'a, braku łatwego testowania napisanego kodu jak najbardziej. A narzędzie skierowane do osób znających Rails'y, rozwijających aplikacje za pomocą metodologi TDD/BDD. Ale nie widzę powodu dla którego każdy nie miałby spróbować.

To ostatnie pytanie jako, że jestem devem Railsów, dlaczego miałbym wybrać ten FW skoro znacznie szybciej, lepiej i sprawniej napiszę to w Railsach? :-) Jedynym 'podobieństwem' jest ORM, więcej nie dostrzegam.

Ouzo powstało jako alternatywa Railsów do PHP bo nie było czegoś takiego. Skoro ktoś może używać RoR, bo to dla niego najlepsza opcja to oczywiste że należy ich używać, niektórzy z różnych powodów muszą zostać przy PHP. Zapewniam Cie że podobieństw jest więcej (migracje, testy).

Migracje to już akurat podciągnąłbym pod ActiveRecord . Nie wiem czy jest taki sens pisać "Yet another testing suite", skoro większość PHPowców używa jednak PHPUnita. Nie zrozum mnie źle, jestem pełny podziwu dla Waszych starań, umiejętności i wiedzy jako dev teamu, ale czy środowisku PHP potrzebuje właśnie kolejnego frameworka? :-)

PHPUnit to kopia pierwszych wersji xUnita. Dla ludzi z doświadczeniem z innych języków (Java, Ruby) używanie PHPUnit to jak podróż w czasie do roku 2004.
Pomimo, że JUnit 4 i PhpUnit dzieli przepaść to w i tak w javie nikt nie używa samego JUnita, zawsze do tego dochodzi np hamcrest, fest-assert, mockito i np guava.

Stan bibliotek tego typu w php jest tragiczny. Pewnie jest to spowodowane tym, że TDD w php nadal raczkuje (rok 2004).

Ouzo to próba wprowadzenia best-practises z innych języków.
Między innymi klasy Arrays i FluentArray, Functions to fasady normalizujące niespójny interfejs funkcji array_xxx. Wzorowane są na jednej z najpopularniejszych bibliotek do javy guavie.
Klasa Strings jest wzorowana na StringUtils z apache commons.
Mock jest inspirowany najpopularniejszą biblioteką do mockowania: mockito (werjsa php Phockito jest ciężka, nie działa z composerem, a kod jest tragiczny i nieutrzymywany).
Assert jest inspirowany biblioteką fest-assertions.

Nie będę wymieniał teraz wszystkiego, odsyłam do dokumentacji, którą staramy się uzupełniać (lub naszych testów, które też służą za dokumentację).

Do kodu Ouzo na bieżąco przenosimy użyteczne klasy z naszych wewnętrznych projektów, więc można się spodziewać nowych ficzerów.

1. Ilość linii kodu jest właściwie bez znaczenia, często ten dłuższy pisze się szybciej, łatwiej i lżej jest dbać o niego, także ten argument jest kompletnie nietrafiony.
2. Przykłady, które podałeś nie są ekwiwalentami. Kod w wersji Symfonowskiej/Doctrine'owskiej ma sporo zalet i różnic w działaniu w stosunku do Ouzowych przykładów.
3. Migracje baz danych są wspierane we wspomnianym Doctrine.
4. Na Doctrine świat się nie kończy w temacie ORM-ów. Skoro już jesteśmy przy Symfony podpowiem, że można w nim spokojnie skorzystać z innego. Czy Ouzo radzi sobie z takim czymś? Jak dobrze? Pytam tutaj konkretnie o możliwości podmiany większości z "pobocznych" komponentów frameworka.
5. W temacie TDD nie widzę niczego specjalnego w stosunku do konkurencji.

No, w końcu coś konkretnego. RoR-a nie znam na tyle by być wstanie samodzielnie ocenić czy tak faktycznie jest, ale jeżeli Twój FW ma być jego PHP-owym odpowiednikiem (oczywiście w granicach rozsądku), to jest to w końcu coś co daje mu jakiegokolwiek plusa na tle reszty.

Nie wiem, nikt niczego takiego mi nie przedstawił, więc nie używam.

@phpsucks - tak samo w Railsach mało kto używa testsuit'a dostarczanego z Railsami, a skupia się na gemach typu Rspec czy Cucumber, jednakże uważam że marnujecie swój czas i umiejętności na tworzenie kolejnego frameworka skoro moglibyście ulepszyć już jakiś istniejący :-)

Chyba sam sobie zaprzeczasz trochę jeśli o coś jest łatwiej dbać to ja biorę to w ciemno bo utrzymam to w porządku.



Czy mógłbyś powiedzieć coś więcej na ten temat? Bo wydaje mi się że ten kod dodaje rekord do bazy danych, dokładnie tak jak w Ouzo.



Rzeczywiście, są - niestety nie wiem jak działają nie korzystałem więc na ten temat nie mogę się wypowiedzieć.



Właśnie po to zrobiony jest built-in ORM aby nie trzeba było korzystać z pobocznych ORM'ów. Jednak wsparcie do tego typu rzeczy, jeśli są one dodawane przez composer jak najbardziej jest ale na poziomie aplikacji.



Nie widziałem aby ktokolwiek miał TestCase do bazy danych, takie które w pełni pomagają przetestować model bez konfigurowania miliarda rzeczy (napisałem inżynierkę w Zendzie i poświęciłem sporo czasu aby testować model).

Jak zwykle bywa przy takiej dyskusji co jest lepsze co jest gorsze pojawiają się bzdurne przykłady wyższości jednego nad drugim. Nie wiem czy to brak wiedzy czy też celowe działanie.

Symfony2 jak i poprzednia wersja nie ma ORMa, więc nie wiem co jest dla Ciebie ociężałe. Dodam, żeORM nie jest jedyną możliwością implementacji modelu w aplikacji, zwłaszcza jeśli utrwalanie odbywa się w API, to też nie jest wymagany przez framework.

To chyba żart skoro napisałeś to w tym samym zdaniu z Symfony2. Tylko proszę nie licytujmy się, że coś jest wygodniejsze bo zabiera mniej lub więcej linijek. Dorzucając do tego istnienie Behata to już kompletnie nie rozumiem o co Ci chodzi.

Jeżeli porównujesz Ouzo do Doctrine2 to ok. Pokaż mi jak zaimplementować Value Objects? Jak wykonać mapowanie typów danych z PostGIS? Dużo czasu zajmie mi podmiana na jakiś silnik NoSQL?

Fajnie, że Wam się chciało. Fajnie, że postanowiliście pochwalić się tym, dobrze wiedząc, że spadnie na Was głównie krytyka. Pytanie czy nie było lepiej skorzystać z gotowych bibliotek (logger, shell itd.)? Oprzeć się na dostępnych już rozwiązaniach dodając swoje pomysły?
Jeszcze jedno mi się przypomniało: jeśli chcę skorzystać z klasy Ouzo\Utilities\Strings to koniecznie cały framework muszę pobierać czy przewidujecie podzielić to na kawałki?

Nigdzie sobie nie zaprzeczyłem. Napisałem tylko, że niejednokrotnie bardziej obszerny kod (pod względem linii) pisze się szybciej i jest go łatwiej utrzymać w porządku. Odniosłem wrażenie, że próbowałeś pokazać zwięzłość kodu Twojego ORM-a jako zaletę - co w tym konkretnym przypadku raczej ją nie jest.
Masz rację, oba kody mają docelowo dodać nowy obiekt do bazy i zapewne robią to podobnie. Jednak ten Doctrine'owy napisany jest z uwzględnieniem zestawu zasad SOLID czyli nie będzie rzucać kłód pod nogi przy próbie zrobienia czegokolwiek co nie jest wręcz do bólu szablonowe. Zwróć uwagę na to, że w Twoim kodzie nie wykorzystam dobrodziejstw IDD, nie rozszerzę kodu poprzez podpięcie zdarzenia, nie zastąpię Twojej klasy Ouzo\Db\QueryExecutor swoją, która robiłaby jakieś dodatkowe rzeczy, długo by jeszcze wymieniać...
Doprecyzuję swoje pytanie: czy jeżeli będę miał taką zachciankę by podpiąć do projektu ORM Doctrine czy inny XYZ, czy po napisaniu kilku adapterów/sterowników i zmianie konfiguracji będę wstanie z niego korzystać z innymi komponentami FW, przykładowo obsługą formularzy lub walidacją?
Zapewne dlatego, że napisanie testów wykorzystujących bazę danych to już zadanie programistów aplikacji, a nie frameworka.

Nie zrozum mnie źle, zapewne na Wasze potrzeby jest do dobre narzędzie i spisuje się jak powinno. Jednak jeżeli nie wprowadza ono niczego ciekawego/nowego/dobrego-z-innych-platform to niestety pochwał zbierać nie będzie.

a dlaczego nie wykorzystacie http://redbeanphp.com/ ?

@aniolekx - nie jestem zwolennikiem ORM w jakiejkolwiek postaci, choć doceniam logikę niektórych narzędzi, ale to co zaproponowałeś jest po prostu mocno popieprzone, gdzie w tym wszystkim jest "easy" ze sloganu?

@piotrooo89 - dobra robota, witamy w gronie ludzi potrafiących napisać solidny framework. Ciekawe ile jest ich na forum, naliczyłem 3... a w Polsce?

@!*! - http://forum.webmastah.pl/topic/2769-polskie-frameworki-php/

Jakiś przykład aplikacji opartej o ten FW ?

Porównujesz ten ORM do Doctrine i rezczywiście wydaje się fajnieszy itp.
ale porównujac go do Eloquent (Laravel) to widzę tu duże prawdopodobieństwo ale bardziej przemawia do mnie Laravel.
Tak jakoś zwróciło moją uwagę, w Twoim ORM

[PHP] pobierz, plaintext 
User::where(array('login' => 'ouzo'))
    ->where(array('password' => 'abc'))
    ->fetch();
[PHP] pobierz, plaintext 

W Eloquent

[PHP] pobierz, plaintext 
User::where('votes', '>', 100)
    ->where('type', '=', 'qwe')
    ->get();
[PHP] pobierz, plaintext 

Niby to samo a jednak brak arrayów wewnątrz where robi dużo dla czytelności.
Ale rozumiem, że możesz to wybronić np. za pomocą "Multiple parameters" z dokumentacji i spójnościa. Rozumiem
No ale chain to chain, taka konstrukcja wydaje się dziwna

[PHP] pobierz, plaintext 
User::where(array('login' => 'admin', 'password' => 'abc'))
    ->where(array('client' => 'ouzo'))
    ->fetch();
[PHP] pobierz, plaintext