🚀 go-pugleaf

On 25 Maj, 10:39, Jaroslaw Zabiello <hipertrac...@gmail.com> wrote:
> Dnia Fri, 25 May 2007 08:46:33 +0200, Piotr 'piter' Hlawski napisał(a):
>
> > that the kind of applications that people are usually allowed to build in
> > Ruby don't have the combination of complex legacy data models, complex
> > business logic and large deployment scale that characterizes interesting
> > projects in the Java world.
>
> Po pierwsze, ten facet nie rozumie, że RoR nie został zaprojektowany aby
> konkurować z wielkimi, korporacyjnymi rozwiązaniami operującymi na
> skompplikowanych strukturach tabel.
>
> Po drugie, jest skrzywiony (wielu javowców tak ma) aby wszystko robić
> "obiektowo i za pomocą ORM'a". Czyli jak już wdepnąć w ORM to na całego.
>
> Tu znowu nie rozumie prostej sprawy. Mianowicie, takie totalne operowanie z
> bazą tylko za pomocą abstrakcji ORM w wielu przypadkach jest znacznie
> bardziej czasochłonne i skomplikowane niż użycie czystego SQL'a.

Oczywiście znasz Hibernate i wiesz, że się da w każdej chwili użyć
czystego SQL'a?

http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#objectstate-querying-nativesql

Mapując sobie w locie na dowolny obiekt.

>Twórcy
> ActiveRecord (i to jest zdaje się napisane w Agile2) wychodzą z założenia
> że ORM ma być pomocą a nie kompleksowym lekarstwem na SQL'a. Czyli
> zakładają że w pewnych sytuacjach lepiej będzie użyć czystego SQL zamiast
> sobie komplikować życie. Dlatego ActiveRecord jest prosty i w ogóle zaletą
> całego Rails jest prostota. A jak potrzeba jakiegoś skomplikowanego
> zapytania i użycie SQL jest łatwiejsze, to po prostu należy użyć SQL'a.

I wiesz też, że Hibernate ma własny język zapytań za pomocą którego
wyrazisz najbardziej pogmatwane struktury danych i jest on niezależny
od silnika baz danych.


Wg mnie w ActiveRecord za dużo jest native sql'a i trzeba uważać na
konstrukcje aby były zgodne z różnymi dialektami.


Climbus