NotORM, skrypt obsługi bazy danych Opcje

[grOm]

Ostatnio buszując po sieci głównie w poszukiwaniu jakichs benchmarków dotyczących Doctrine2 natrafiłem na ciekawe porównanie/prezentacje http://www.notorm.com/static/doctrine2-notorm/
Ściągnąłem ten skrypt przetestowałem i wydaję się że ma niezły potencjał, ogarnięcie co i jak zajęło mi dosłownie godzinę, lekkość i szybkość biblioteki jest nieporównywalna do Doctrine2.
Skłaniałbym się do używanie tego wyłącznie do front endu ze względu na szybkość, Doctrine2 posiada jednak wiele ułatwień przy produkcji back endu
Chciałem się dowiedzieć co myślicie o tym całym NotORM ?

[Crozin]

Widziałem już to "porównanie" - można by je porównać do prezentacji n/t rządów PO stworzonej przez PiS czy na odwrót.

W skrócie:
1. Ej patrzcie, jak zrobicie literówkę to skrypt nie działa.
2. Ej patrzcie, jak podacie złą nazwę klasy to skrypt nie działa!
3. Ej patrzcie, projekt Doctrine korzysta z elementów innego projektu - Symfony. O nie! Nie napisali wszystkiego sami tylko wykorzystali gotowe narzędzie.
4. Ej patrzcie, żeby rozpocząć pracę z Doctrine trzeba napisać (skopiować jak się nie chce) więcej niż w przypadku NetORM. Co z tego że w normalnym użyciu ilość kodu będzie porównywalna. Ten argument jest w sumie bardzo często stosowany. Przecież od dawana wiadomo, że PHP deklasuje Javę, bo Hello World w nim to raptem jedna linijka tekstu:

[PHP] pobierz, plaintext 
<?php echo 'Hello world!';
[PHP] pobierz, plaintext 

A w tej paskudnej Javie aż 5

[JAVA] pobierz, plaintext 
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}
[JAVA] pobierz, plaintext 

Ten NetORM z tego co widzę po źródłach to przesycony magicznością skrypcik, który polegnie przy pierwszej próbie zrobienia czegoś niestandardowego, wykraczającego poza najprostsze operacje CRUD.

[Gribo]

a co sądzicie o http://www.phpactiverecord.org/ ?

[erix]

A CakePHP przypadkiem tego nie ma?

[grOm]

To nie ma nic wspólnego z cake php
Nie zważając na wasz sceptycyzm napisałem w całości sklep dzięki właśnie notorm + zf1 i wyszło mi to bardzo sprawnie : )
Ktoś tam pisał że zaawansowane zapytania ciężko w tym napisać - może to być nawet prawda ale przy naprawdę zaawansowanych zapytaniach, ale takie zapytania pisałem po prostu w PDO.
Najczęściej jednak wystarczały proste joiny typu $product->product_parameter()->select('parameter.name, product_parameter.*');
Najfajniejsze jest to że nie ma potrzeby przepisywania struktury tabeli do modeli i ustawiania w nich relacji, wszystkie relacje ustawia się z poziomu phpmyadmin lub adminer'a jak kto woli.

[Crozin]

Fajnie jakbyś mógł pokazać ten projekt - można by konkretny argumenty za i przeciw poprzeć konkretnymi przykładami użycia z kodu. Ale jak się domyślam jest to zapewne projekt komercyjny.

Ktoś tam pisał że zaawansowane zapytania ciężko w tym napisać - może to być nawet prawda ale przy naprawdę zaawansowanych zapytaniach, ale takie zapytania pisałem po prostu w PDO.

Co prawda nie wiemy co to są "zaawansowane zapytania" w tym przypadków, ale koniec końców każdy ORM polegnie na tym polu. Jednak te sensowniejsze pozwalają na wykonanie czystego zapytania przy jednoczesnym mapowaniu wyników na obiekty. Jak się tutaj spisał NotORM?

Najczęściej jednak wystarczały proste joiny typu $product->product_parameter()->select('parameter.name, product_parameter.*');

JOIN-y to akurat tak podstawowy element wszystkich ORM-ów, że nie ma tutaj w sumie czego porównywać. Wszystkie to powinny obsługiwać w łatwy sposób.

Najfajniejsze jest to że nie ma potrzeby przepisywania struktury tabeli do modeli i ustawiania w nich relacji, wszystkie relacje ustawia się z poziomu phpmyadmin lub adminer'a jak kto woli.

Większość, jeżeli nie wszystkie, z szanujących się projektów udostępnia kilka narzędzi pomocniczych typu budowa schematu bazy danych na podstawie struktury obiektów w aplikacji czy na odwrót, tj. przygotowanie całej konfiguracji na podstawie schematu z bazy danych.