🚀 go-pugleaf

On 27 Maj, 00:00, "Jaroslaw Zabiello" <hipertrac...@gmail.com> wrote:
> Dnia 26-05-2007 o 19:59:01 climbus <clim...@gmail.com> napisał(a):
>
> >> Masz na myśli HQL? Wiele osób go krytykuje.
>
> > Wiele osób krytykuje Railsa
>
> Więcej go chwali.

Nie widziałem takiego porównania. Popatrz, że  widzisz to z
perspektywy swojego środowiska.

>
> > Rozumiem, że łatwiej nauczyć się kilku dialektów SQL'a.
>
> Nie są aż tak różne, a HQL to raczej już inny język.
>

Ale bardzo upraszczając,  pisząc w tym języku nie musisz wiedzieć pod
jaka bazą będzie chodziła aplikacja. Przy SQL już musisz.

> W tym, że zwykle bazy relacyjne dostarczają narzędzia do optymalizacji i
> testowania SQL'a. A Hibernate ze swoim HQL jest raczej zamkniętym światem
> sam w sobie.
>

Na końcu masz sql więc możesz go sobie do woli testować a potem masz
pełny wpływ na generowany sql wiec możesz go sobie optymalizować.

> > Część optymalizacji myślę (akurat nie jestem pewien) robi Hibernate
> > znając specyfikę danego
> > dialektu, zna specyfikę silnika.
>
> Musisz polegać na czarnej skrzynce Hibernate. Nie możesz wykonać własnych
> optymalizacji lub byłoby to bardzo trudne, bo nie masz żadnych narzędzi
> wspomagających taki proces.

To nie jest czarna skrzynka, masz wpływ na generowany i uruchamiany
sql i tak samo możesz ten sql optymalizować. Jaka  tu przewaga Railsa?

> Jak to co? Zamapuj to w Hibernate jak takiś mądry. Tak aby to było
> "niezależne od silnika bazy"

Tworzenie tabeli zamapować? Tego się nie mapuje. Jak masz stworzoną
tabelę w mysql to już baza dba o sortowanie i nie rozumiem co ma do
tego hibernate?

> > Zawsze można znaleźć jakieś konstrukcje lub ficzery, które nie są
> > przenośne, lecz nie w tym rzecz.
>
> Ano w tym że padła teza że Hibernate potrafi obejść różnice między
> silnikami baz. Nie ma takiego ORM'a i raczej nie będzie. A jeśli nawet
> ktoś podejmie się mapowania bardziej skomplikowanych struktur to kosztem
> złożoności i w takim wypadku SQL jest po prostu znacznie prostszy. To jest
> ogólny problem wszelkich ORM'ów. Dlatego uważam że ich celem jest
> uprościć i pomóc programiście w pracy a nie kompletnie wyeliminować SQL'a.
>

A kto tu mówi o kompletnym wyeliminowaniu SQL. Hibernate daje więcej
możliwości użycia SQL'a i wpływu na generowany SQL niż Active Record.
Jeżeli masz taką potrzebę masz pełną dowolność.

> Moc całego ROR to czytelność i prostota. Prostota jaka jest nieosiągalna w
> rozwiązaniach dla Javy.

Mówimy o samym orm. Jeżeli wywołujesz czysty sql to róznica będzie
minimalna. Tu i tu sql będzie równie czytelny.

> Zresztą jak byś określił JRuby on Rails? To
> projekt javowy czy nie? Generuje bytecode JVM i ma dostęp do wszelkich
> bibliotek Javy. Sam Active Record JDBC korzysta z plików JAR.

Pomyłka?

> Zdaje się że ten projekt jest w fazie embrionalnej. Ale widocznie są tacy
> co wolą podejście czystego SQL. Tak jak i są tacy co wolę framework Nitro
> niż Rails. Kwestia gustu.

Właśnie. Kwestia gustu.


> Toś chyba nie widział pluginu ez_where. Polecam popatrzeć nahttp://brainspl.at/articles/2006/01/30/i-have-been-busy

Implementacja czegos podobnego co Hibernate ma od początku.

> > Przy bardziej skomplikowanych zapytaniach i warunkach robi się bałagan.
>
> Jak są bardzo skomplikowane to zawsze można użyć czystego SQL'a. Będzie
> pewnie prościej niż obiektowe łamańce składniowe.

I prościej do sql injection

> > Hibernate ma "criteria"
> > które można łatwo dodawać a wszystko jest parsowane pod względem
> > typów.
>
> A co typy tu mają do rzeczy?

To że nie włożysz do sql innego typu niż zakładałeś. np jak ma być int
to będzie tylko int.

>
> > A jakie środowisko krzyczało, że jest Java killerem. Że Java umiera.
>
> Kup sobie "Więcej niż Java" Helionu to będziesz wiedział co krytykujesz.
> To teza z tej książki. Oczywiście że RoR jest wybawieniem od pogmatwanych
> javowych rozwiązań w sytuacji średniej klasy złożoności gdzie masz
> stworzyć lekki fronton operujący na relacyjnej bazie danych. Martin Fowler
> i szereg znanych postaci ze świadka javowego nie bez powodu chwalą Rubiego.

Od dawna java nie jest mocna w tym obszarze. Po prostu nie było
niczego lepszego więc używano na siłę Javę.

> Do bardzo dużych, skomplikowanych, rozproszonych systemów, pewnie długo
> nie będzie konkurencji dla Javy. Ale to nie jest dziedzina w ktorą chce
> wedrzeć się Ruby i Rails. Dlatego myślę, że oba podejścia mogą się
> uzupełniać. Np. znam firmę gdzie duży system pracuje w Javie ale szereg
> powiązanych z nim (mniejszych) projektów ma być w Ruby on Rails.

Często się o tym zapomina. Trzeba o tym mówić, że Rails chce skubnąć
trochę rynku w obszarze małych projektów.

> Sun lansował kiedyś tezę że Java jest dobra na wszystko. Ta teza nie
> wytrzymała próby czasu.

To już dawno jest jasne, że sie pomylił. Teraz trzeba poczekać jak
przyjmie próbę czasu Rails.

> Rewolucje zawsze były dziełem młodych i gniewnych
> więc się nie dziw. :) Java z tymi wszystkimi swymi bibliotekami rozrosła
> się do niebotycznych rozmiarów. Można się tym udławić. Latami można się
> tego uczyć. A większość projektów to nie są projekty wielkiej skali i
> wielkiej złożoności.

Z ta większością bym polemizował. Mniejsze projekty dawno przejął php.

> I tu Ruby i Rails jest jak powiew świeżego powietrza.
> Wykosi Javę z takich projektów to pewne.

Skubnie trochę rynku. I tak sztucznie zajmowanego przez Javę bo oprócz
PHP nie było alternatywy.

> Oni też zostali zarażeni pomyślami jakie wprowadził Rails. :) I dobrze.

Oni od początku szukają dobrych i rewolucyjnych rozwiązań.

> Ale nie wiem czy to coś im pomoże. Sam Spring jest pod obstrzałem nowego
> JEE 5.0, pod obstrzałem krytyki ze strony JBoss czy tak jakoś.

Duża firma atakuje drugą dużą. Nic w tym dziwnego. Na razie się dobrze
bronią.


--
Climbus
http://blog.netstation.pl/