Ну, аннотации - ещё куда ни шло.

>Ну, аннотации - ещё куда ни шло.

Это смотря с какой стороны посмотреть. Хайп по поводу аннотаций и прочего "аттрибут ориентированного программирования" ИМХО весма переоценен. Во внешних конфигурациях есть возможноть, например, подключать сторонне компоненты без влезания в их код. Например я когда-то писал микроядерный аппсервер кустомный - так мне не было нужды аннонировать чужие JMX реализации или стандартные томкеты и прочие либы, для запуска ядре, равно как и для развертывания левых компонентов в левом же JMX, и эти компоненты вообще нефига не знали, что стали managed beans.

Аннотации подходят для небольших проектов c class for only one use. Экстернализация конфигурации есть безуаловный гуд. Почему-то все забывают что аналог аннотаций например для апача - это вместо apache.conf - компиляция апача при изменении настроек.

>чего только не придумают, чтобы не использовать ROR

меня всегда интересовало почему любители Ruby все время хвастают, что Ruby - это почти Smalltalk. так почему бы не взять настоящий Smalltalk, где есть среда с браузером классов, рефакторингом, юниттестами, комплетшном и т.п., огромной библиотекой классов и кучей фреймвоков (по теме - например http://www.seaside.st )?

>>>Grails использует Spring, а Spring - это EJB

>> Spring - это альтернатива EJB.

>Я до этого места ещё не дочитал, спасибо. Однако, "Spring Framework is the leading full-stack Java/JEE application framework". Кроме того, "central focus of Spring is to allow for reusable business and data access objects that are not tied to specific J2EE services. Such objects can be reused across J2EE environments (web or EJB), standalone applications, test environments, etc without any hassle."

1) Spring - это JEE framework
2) JEE != EJB
3) Spring может работать с EJB(если у тебя есть legacy код это важно)
4) Авторы спринга активно рекомендуют не использовать EJB ни где (я присоединяюсь)

итого Spring - это _НЕ_ EJB.
Так понятней?

>так почему бы не взять настоящий Smalltalk, где есть среда с браузером классов, рефакторингом, юниттестами, комплетшном и т.п., огромной библиотекой классов и кучей фреймвоков

Там слишком грамотная библиотека.

а вот скажи как специалист, а зачем вообще все эти ОРМы, я вот не могу понять где ассоциативный массив будет хуже, кроме того что перевод полей в методы само по себе замедляет работу?

>а вот скажи как специалист, а зачем вообще все эти ОРМы

Затем, что я в одном месте описываю поля записи БД в духе:

    function main_table_fields()
    {
        return array(
            'id'        => 'ID',
            'title'     => 'Header|html_entity_decode',
            'source'    => 'Text|aviaport_old_denormalize',
            'description'   => 'announce|html_entity_decode',
            'create_time'=> 'UNIX_TIMESTAMP(Date)',
            'modify_time'=> 'UNIX_TIMESTAMP(Modification)',
            'type_id'   =>  'Type',
...

И потом в любых местах программы юзаю $obj->title() или
$obj->set_create_time(time(), true); не забивая себе голову тем, как оно
будет грузиться из БД или как будет сохраняться при изменении
полей объекта. И если завтра у меня что-то поменяется
в структуре БД, то изменить придётся только эти несколько строк.

...

В общем, грамотная ОРМ позволяет на порядок уменьшить объём
писанины. А хороший программист должен быть ленив.

ну и это вот как раз вы описали ассоциативный массив только зачем то обернули его в функцию. а то чтобы оно само разбиралось с синхронизацией мапированных данных с реальным сторейджем достаточно колбеков. вопрос остался открытым.

> Объясните идиоту в двух словах, что такое EJB и какие конкретно цели оно решает. На Википедию не посылать.

Аббревиатура OR-Mappng (Object Relationship Mapping) ни о чём тебе не говорит?
Так вот, EJB это фреймворк, который позволяет представить записи таблиц, их связи и хранимые процедуры СУБД в виде объектов, с которыми можно работать на человеческих языках программирования типа Java и писать бизнес-логику не в "простынях" SQL-выражений, а в комфортных условиях Java-IDE, которые поддерживают мощный рефаторинг и верификацию кода. В них мало ошибаются.

Объекты, естественно, создаются не на дисках, а в оперативной памяти (и на дисках в свапах, если памяти мало :) ). Могут быть сериализованы (представлены в бинарной форме) по сети, сохранены в файловых хранилищах, отданы другим EJB-серверам для обработки в составе других баз данных и т.д.

Просто бизнес-логика на SQL с какого-то момента стала сложна для сопровождения и понимания. Решили заменить SQL на EJB (не полностью).

> нету на обычном хостинге никагого Tomcat или даже простой jvm.

Неправда! На моём локалхосте есть: http://87.119.238.145/ (IP-адрес динамический).

>ну и это вот как раз вы описали ассоциативный массив только зачем то обернули его в функцию

Потому что функции можно перекрывать при наследовании. И это очень часто делается. Это во-первых. Во-вторых, принципиальной разницы между заполнением полей объекта и записей хеша нет. И то, и другое изофаллически. Всё равно это - ОРМ. Только с хешем попримитивнее и с меньшим функционалом, с объектом - понавороченнее, но и куда функциональнее.

не позикстивно

ну во первых есть метатаблицы для симуляции наследования (если брать луа)

наследование само по себе тоже в контексте работы с причесанными данными странно, ведь по сути это либо способ модуляризации кода, либо усложнения типа.

вот а хеш все ж значительно быстрее и легче решение

про функциональность не убедительно

>наследование само по себе тоже в контексте работы с причесанными данными странно

Как только у тебя становится более одного варианта хранения данных - ничего странного. Для этого объекта title() - это поле из БД, для этого - фиксированный текст, для этого - комбинация из нескольких других полей в БД и т.д. А работа с ними - унифицированная. Системе, которая будет рендерить объект в HTML по заданному шаблону это пофиг. Есть метод title() - его и рисуем.

> а вот скажи как специалист, а зачем вообще все эти ОРМы, я вот не могу понять где ассоциативный массив будет хуже, кроме того что перевод полей в методы само по себе замедляет работу?

и как тебе хеш поможет построить join ?
что-нибудь вроде:
@artists = Artist.find_all_by_artist_title(params[:id], :include=>[ :albums => [ :labels, :genres ] ] ?

>и как тебе хеш поможет построить join ?

Я так понял, что он хеш имеет в виду как хранилище уже выдернутых данных, вместо полей объекта. К формату описания маппинга данных оно отношения не имеет.

Хотя, если иначе - то тогда он не прав :)

>про функциональность не убедительно

Мне надо выбрать группы и студентов в группах. Любой orm это делает приблизительно так:

Groups.all().

Внутри сгенгерируется максимум 2 запроса.

Я все сделал.

НУка пример с хешами в студию.

ну это дело регламента синхронизации мапа на сторейдж, это можно и с хешем решить.

да джойн в модели прописывается в хеше уже все сджойнено

яволь

как вариант сделать новую модель с объединением таблицы группы и таблицы студентов и выбрать из нее все. это вообще будет один запрос

хотя допускаю что я недопонял смысл вопроса

>это вообще будет один запрос

Я сказал максимум. Орм тоже недурак. Можно реализвать 2мя запросами можно одним. Не факт что в данном случае 1 быстрее.

НУ а по результату - он уже будет разобрат во вменяемую структуру. Результат и одного и двух запросов структура слабо вменяемая.

На Groovy никто не пишет и они решили переманить прогеров у пхпэшников. Мне катца, что из этого ничего не получится. Уже был Curl. Ну и кто на него перешёл?

не вижу невменяемости простого хеша как я понимаю все эти ормы - это:

1. отразить данные в память для быстрого манипулирования (считай кеш)

2. отразить таким способом, чтобы было удобно работать с ними из языка

3. на любую требуемую структуру данных нужно строить модель

>Так вот, EJB это фреймворк, который позволяет представить записи таблиц, их связи и хранимые процедуры СУБД в виде объектов,

не совсем так. есть например Session или MessageDriven Bean-ы, кот-е к CУБД вообще никакого отношения не имеют. ejb - это просто управляемые компоненты (классы), которые живут в соответствующих (ejb) контейнерах, которые могут управлять их жизненным циклом, умеют распределенные транзакции (JTA), удаленные вызовы (RMI), часто всякие там JMX, кластеризацию и т.п. сериализация в СУБД это свойство только Entity Bean-ов, которых в приложении вполне может и не быть. ( например до EJB3.0 очень многие вообще не пользовались этим геморроем ( Entity Bean-ами ), а пользовались тем же Hibernate-ом или JDO ).

я добавлю я не против MVC я не очень просто понимаю зачем строго данноориентированную структуру БД отражать на объекты.

имхо либо уж хранить нормальные объекты как хранит смоллтолк в образе.

а то вроде работают с объектами а ничего в них объектоного нет лишняя дорогая прослойка

>ну это дело регламента синхронизации мапа на сторейдж, это можно и с хешем решить.

И в конечном итоге у тебя будет система, которая и представит из себя то, что называют ORM :)

верно но зато эт обудет легковеснее и распространяться не на ООП языки

>я не очень просто понимаю зачем строго данноориентированную структуру БД отражать на объекты.

«Строго» - не обязательно. Скажем, мой фреймворк через свою ORM пристраивается к уже имеющимся БД совершенно разнокалиберных форматов. В примере выше, как раз, реальный кусок. Там и преобразования данных (скажем, mysql-DATE -> unixtime, или escaped-данные в обычный вид и обратно), и выдёргивание фрагментов из разных таблиц или даже данные (те же join'ы). А на объекты отображать - да потому что это очень удобно :) И логично. Я года четыре использовал систему безобъектную. В итоге, по мере её развития, дошёл фактически до эмуляции объектов. Но урезанной и не очень функциональной. Перевёл всё на настоящие объекты - система стала намного нагляднее, проще (и по структуре и по объёму кода) и даже быстрее :) Хотя до сих пор приходится тащить массу старого кода и костылей для объединения разных подходов, полторы тысячи файлов в один день не перепишешь, но теперь зачастую переписать какой-то модуль на объектную систему становится быстрее, чем расширить функционал старого, необъектного :) Плюс к тому - система стала намного более гибкой, нет никакой привязки к формату исходных данных, Model полностью отвязана теперь от Controller :) (View, слава Богу, у меня был отвязан изначально).

>верно но зато эт обудет легковеснее

Увы, нет. Сложная необъектная система оказывается (в данном контексте) тяжелее простой объектной, выполняющей тот же функционал.

>и распространяться не на ООП языки

А это уже, во-первых, не важно в рамках одного проекта, во-вторых, в случае смеси языков никто не мешает в необъектном объектами не пользоваться :) Всё равно в БД формат необъектный. В-третьих, что у нас из языков соответствующего профиля (Web и работа с БД) - необъектное?

Что такое ORM, я знаю, и работал с некоторыми (правда, несложными, уровня того же ActiveRecord). И согласен, что это очень удобная вещь по сравнению с прямой работой с SQL.

То есть EJB - это объекты с поддержкой persistency?

>> нету на обычном хостинге никагого Tomcat или даже простой jvm.

> Неправда! На моём локалхосте есть: http://87.119.238.145/ (IP-адрес > динамический).

Уменя тоже может быть и х_уле ??? ПРокеты хостить на домашнем компе чтоли.

>То есть EJB - это объекты с поддержкой persistency?

Нет, это такая херня которую можно дернуть по RMI/IIOP и которые исполняются в транзакционной, кластеризуемой среде под управлением контейнера.

Короче хочешь ты узнать uptime так чтобы из ремотного клиента и интерорбу, так чтобы это было в рамках распределенной транзакции да еще и жило на кластере? Ну вот это они и есть.

Ничего не понял... сплошной поток баззвордов :(

Ладно, видно, не для моего это убогого умишка.

> Объясните идиоту в двух словах, что такое EJB и какие конкретно цели оно решает.

EJB - Enterprise JavaBeans - компонентная архитектура для построения приложений. Включает в себя жёсткие стандарты именования классов, что позволяет им взаимодействовать друг с другом.

> Это я и хотел сказать. нету на обычном хостинге никагого Tomcat или даже простой jvm.

А где можно посмотреть обычный хостинг?

> Так понятней?

Да, я вроде так и сказал ;)

эээ... чувак, ты не попутал EJB с Hibernate?

>То есть EJB - это объекты с поддержкой persistency?

EJB бывают разные
1. Entity Beans - они работают с БД
2. Message Beans - ни какого отношения к БД не имеют. Работают как сообщения
3. Session Beans - хранят состояние сессии

J2EE - это набор спецификаций.
EJB - часть J2EE
JSP - часть J2EE
Spring - частично имплементирует J2EE функциональность

J2EE 2.x - монстр. J2EE 3.0 - значительно переработанные спецификации и по простоте имплементирования приближаются к Spring.
Хотя я лично предпочитаю Spring, EJB3 выглядят очень привлекательно

>3. Session Beans - хранят состояние сессии

Жесть.

>3. Session Beans - хранят состояние сессии

> Жесть.

Частино согласен, жесть :)

Есть Statefull Session Beans где можно хранить сессию.

Stateful session beans are distributed objects having a conversational state. The state could be persisted, but access to the bean is limited to only one client.

>Spring - частично имплементирует J2EE функциональность

Какую часть? имплементирует и использует разные вещи.

>Entity Beans - они работают с БД,

А Message и Session бины не работают? Т.е мой Session бин ну никак в базу не залезет.

>Session Beans - хранят состояние сессии

какой сессии?!!!!

>Message Beans - ни какого отношения к БД не имеют. Работают как сообщения

Ахтунг, боты заботали Сократ!!!

Конкурс на худшее определение JEE

>Включает в себя жёсткие стандарты именования классов, что позволяет им взаимодействовать друг с другом

Боты в городе или SUN заказал локализацию каким то горе ЛОХализаторам или лоКАЛЛизаторам?

Или это конкурс на лоре, кто не знает J2EE лучше всех?

PS Никаких ЖЕСТКИХ СТАНДАРТОВ именования классов ни в EJB ни в JEE нет.

> не совсем так.

Вот ты сейчас с кем разговаривал? (с) ералаш

Короче, я так понял, что любители ынтырпрайза сами между собой переругались в терминологии. К чему, собственно, всё и шло...

>Боты в городе или SUN заказал локализацию каким то горе ЛОХализаторам или лоКАЛЛизаторам?

Вот ты такой умный, так напиши внятно, как ты считаешь, а не верещи, что все не так.

>А Message и Session бины не работают? Т.е мой Session бин ну никак в базу не залезет.

Может, но это не кошерно

>А Message и Session бины не работают? Т.е мой Session бин ну никак в базу не залезет.

JSP тоже может в базу лазить, но тогда это ни чем от PHP отличаться не будет.

>>А Message и Session бины не работают? Т.е мой Session бин ну никак в базу не залезет.

>Может, но это не кошерно

Чем это не кошерно? ;-)

CMT без Entity Beans никак поюзать нельзя? ;-)

До EJB3 все кому доводилось работать ejb под нагрузкой юзали Session бины только для Remoting'a и Container Managed транзакций.

Да и сейчас для batch updates если уж кому придет в голову EJB пользовать то только session statless.