ScalaQL, ассиметричный ответ на LINQ

> Моя ложка дегтя: не совсем корректо использовать DAO с Hibernate (ну или что у вас там JPA etc), аргумент из того срача с серверсайд который мне больше всего понравился- вместо DAO (Data Access Object) для Hibernate нужно что-то вроде EAO (Entity Access Object), который умеет делать не CRUD, а PRADR (Persist, Retrieve, Attach, Detach, Remove)

Ну, пусть будет EAO, я не понимаю, почему некорректно?

Насчёт Attach/Detach - это действительно нужно? Это означает, что сущности могут приходить в сервис извне и их приходится аттачить в контекст? Может, проще передать pk этой сущности или любую другую информацию, чтобы эту сущность достать из DAO, и в рамках этого persistence контекста работать с ней? Учитывая, что всё это дело кэшируется, то за этим даже не последует селекта. А detach мне вообще никогда нужен не был...

> Насчет "Аргументов в пользу DAO": это аргументы в пользу DAL. DAL != DAO. DAO это одна из реализаций DAL.

А какие ещё есть реализации?

>Хех, с EJB3 не работал, но коль такая пъянка погуглил. Там везде в Stateless бине (т.е. сервисе) просто дергают методы EntityManager, используя его как DAL. Забавно.

Вот я про то и говорю, что такой подход в 95% случаев себя вполне оправдывает. И нафиг не надо в тех-же 95% случаев городить еще и дополнительный слой бинов.

> Хех, с EJB3 не работал, но коль такая пъянка погуглил. Там везде в Stateless бине (т.е. сервисе) просто дергают методы EntityManager, используя его как DAL. Забавно.

EJB - это вообще самое гадкое, что есть в J2EE, и история мутации спецификации на них это подтверждает. Не надо с них брать пример. :)

> И нафиг не надо в тех-же 95% случаев городить еще и дополнительный слой бинов.

А что ты подразумеваешь под бинами здесь?

> List result = em.createNamedQuery("Something.byName").setParameter("name", name).getResultList();

Типичная ООП-жесть. Для простейшей выборки уйма телодвижений.

> Дело в том, что хибернейт часто применить либо избыточно, либо нереально. Что бы его использование было целесообразным нужно совпадение целого ряда факторов: СУБД, схема бд, предметная область ну и наличие опыта работы с такого рода решениями.

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

> Типичная ООП-жесть. Для простейшей выборки уйма телодвижений.

Да лана, вроде всё просто, а как должно выглядеть (можно псевдокодом)?

>Это означает, что сущности могут приходить в сервис извне

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

>Ну, пусть будет EAO, я не понимаю, почему некорректно?

Ну DAO как бе по определению работает либо с записями (ResultSet, Map etc), либо с Data Transfer Objects (что все и делают, но фаулер негодует), а не с сущностями.

>А какие ещё есть реализации? DAO это шлюз таблицы (один экземпляр на одну таблицу); Шлюз записи (один экземпляр на одну запись и статик finders); И то, что следует использовать с сущностями - Data Mapper. Hibernate это и есть Data Mapper (точнее Data Mapper + Identity Map + Unit Of Work). Получается, что поидее как это Hibernate и есть DAL. Хотя лучше обернуть Session во что-то (EAO), чтоб HQL не размазывать по сервисам.

> Как толсто! Вы пятиклассник?

Нет, но у меня под наблюдением три группы юных кодеров .NET (на каждом курсе), и это результаты наблюдений за ними.

> Понятно - не для простых смертных. Типа "элита".

Для другой задачи, а не аудитории -- не чтобы работало, а чтобы "publish, not perish".

> Да лана, вроде всё просто

Да уж, проще не куда. На псевдокоде, пожалуйста:

set result [select * from something where name = $name]

> Я так понимаю сущности извне приходить никак не могут, приходят DTO, которые аттачаться. В общем я же говорю в жизни ни разу не видел реально работающей "правильной" реализации всей этой байды.

Хорошо, если приходят DTO, из них создаётся сущность и аттачится в контекст - я всё равно не вижу проблемы тут.

> Ну DAO как бе по определению работает либо с записями (ResultSet, Map etc), либо с Data Transfer Objects (что все и делают, но фаулер негодует), а не с сущностями.

DAO - это объект, обеспечивающий доступ к данным, EAO - тот же DAO.

> Хотя лучше обернуть Session во что-то (EAO), чтоб HQL не размазывать по сервисам.

Полюбому лучше персистенс отделить от логики.

> Да уж, проще не куда. На псевдокоде, пожалуйста:

> set result [select * from something where name = $name]

Ну не слишком-то и короче. А какой здесь используется диалект SQL? Я понимаю, что селекты более менее схожи везде, но всё же. ))

> List result = em.createNamedQuery("Something.byName").setParameter("name", name).getResultList();

Хочется кого-то убить.

>Да уж, проще не куда. На псевдокоде, пожалуйста:

>set result [select * from something where name = $name]

и чем это проще jpa-шного кода? то-же самое создание запроса, подстановка параметров и выполнение запроса.

>Хочется кого-то убить.

А можно поподробнее? что не так с этой строчкой.

> set result [select * from something where name = $name]

Кстати, на Scala вполне можно сделать такое. То есть такую либу, которая после подключения учит Scala понимать строки вида

val result = SQL[select * from something where name = $name]

Название языка Scala - это от Scalable. Раз такое нужно, попробую написать, вот только книгу по Lift дочитаю сначала, по работе нужно... Сначала работа, а фан потом.

А осилить STP и забыть про все эти велосипеды. Слабо?
Логичнее чем обрабатывать данные на стороне данных - сложно что-то придумать.

>EJB - это вообще самое гадкое, что есть в J2EE, и история мутации спецификации на них это подтверждает. Не надо с них брать пример. :)

Да ладно, с третьими уже вполне комфортно можно работать.

> А можно поподробнее? что не так с этой строчкой.

См. историю появления LINQ, там объяснялись цели и задачи. Попробуйте есть не так много OOP и поймёте сами...

Не короче, но проще для восприятия. Почти чистая декларативщина. И это не SQL, а лишь SQL-like интерфейс. Что там будет под капотом - вопрос реализации. Насколько я понял, ScalaQL - это нечто подобное, только более обобщенное.

> А осилить STP

Что это?

Неужто Stored (T?) Procedures?

> Да ладно, с третьими уже вполне комфортно можно работать.

Что 3-и лучше это несомненно, но я застал самый кайф от EJB2.1. =)

>> А осилить STP
> Что это?

STored Procedure.

> А осилить STP и забыть про все эти велосипеды. Слабо?

Ещё один Петросян.jpg :D

> STored Procedure.

Это вариант. На мой вкус даже лучший, чем ORM. Но имеет свои серьёзные недостатки.

>Что 3-и лучше это несомненно, но я застал самый кайф от EJB2.1. =)

Ну до третьих это реально был полный пи...ц. Поработал я пару месяцев с ними (там не только session, но и entity бины юзались), до конца жизни не забуду.

>STored Procedure.

Они хороши только в одном случае - когда надо пару гигов raw данных внутри базы переколбасить. Но необходимость такого говорит всего-лишь о кривости системы.

> Это вариант. На мой вкус даже лучший, чем ORM. Но имеет свои серьёзные недостатки.

Ну потеря утопичной абстракции от бд это спорный недостаток, зато есть возможность использовать особенности конкретной бд на полную улучшая производительность.
То что код лежит отдельно от остального и, чаще всего, вне системы контроля версий - недостаток.
Больше проблем я не вижу.

> Они хороши только в одном случае

Они хороши везде. Вы не умеете их готовить.

>DAO - это объект, обеспечивающий доступ к данным, EAO - тот же DAO.

Вот DAO: http://martinfowler.com/eaaCatalog/tableDataGateway.html
Вот EAO: http://martinfowler.com/eaaCatalog/dataMapper.html

>Больше проблем я не вижу.

Построение динамических запросов (например, поиск)?

Либо придется плодить кучу процедур, либо писать в WHERE что-то типа (LAST_NAME IS NULL OR LAST_NAME = $name). Это может привести к тому, что оптимизатор выберет плохой план выполнения запроса.

> Построение динамических запросов (например, поиск)?

внутри stp сложно сделать динамический запрос?
на входе имя поля и искомая строка.
да и не так часто нужны динамические запросы.

>>> List result = em.createNamedQuery("Something.byName").setParameter("name", name).getResultList();

>>Хочется кого-то убить.

> А можно поподробнее? что не так с этой строчкой.

Тонко.

На случай, если это не троллинг - это длинная и уродливая строчка. Кстати, что, если нужно установить 2 параметра?

> STored Procedure.

Они как бы один большой антипаттерн уже лет десять как. Я согласен на любые ORM вместо них, даже самые ушибленные OOP %)

> Они хороши везде. Вы не умеете их готовить.

1. Допустим, я решил сменить SQL-сервер.

2. Как их лучше всего класть в VCS?

3. У меня inner join с сотней полей, по каждому из которых может быть group by, where сложным образом и т.д. в зависимости от желания пользователя-аналитика (было сказано -- "везде")

>И кто реально использует в enterpriZe это яйцеголовое поделие, когда есть мегарулезный Hibernate?

Sony, Xerox.....

Hibernate атцтой.

>Как кластеризацию на pure-JDBC (без всяких этих хиберских кешей второго уровня типа Swarm) делать будем?

Легко и просто - проблемы с кэшами второго уровня при кластеризации возникают как раз только в ормах где есть эти кэши второго уровня.

>еперь нам нужно еще добавить к нашему DAO возможность сделать Attach/Deattch объекта, а сессию хранить не внутри DAO а в сессии запроса. Типа так: https://www.hibernate.org/43.html. Зачем делать attach\deattach? Service-layer должен оперировать с Data Transfer Objects, а не Persistance. Т.е. делаем deattach, а затем трансформацию в DTO. Так что просто так DAO в нашем случае сменить сменой конфига нельзя, т.е. теряется его суть.

Угу - и изза этого всего бреда все почему-то забыли что единственное что они делают эо табличное представление в базе, показывают в виде таблиц на вебе. Но все с увлечением детачаться объектами которые ненужны. То есть _вообще_.

> Легко и просто

Пожалуйста, пример в студию.

Я свой ответ обосновал кодом файла конфигурации связки Hibernate+Spring.

Мог дать полный пример кода.

>забыли что единственное что они делают

Никто не забыл. У меня для таких случаев DAO, который возвращает List<Map<String,Object>>.

> Sony, Xerox.....

Пруфлинк в студию.

> Hibernate атцтой.

Да ну! А обосновать?

>Допустим, я решил сменить SQL-сервер.

Есть два случая: продукт под интранет и опенсорцный вебдваноль. Оба этих случая исключают смену SQL сервера. В первом случае незачем менять то что и так работает, а во втором будет использоваться нечто типа MySQL.

>Как их лучше всего класть в VCS?

Скрипт создания БД.

>У меня inner join с сотней полей, по каждому из которых может быть group by, where сложным образом и т.д. в зависимости от желания пользователя-аналитика

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

>>Как нахрена, ё моё, вы из сервиса хотите сразу с зибернейте сессией или подобным работать? O_o

> А в чем проблема работы с хиберовской или jpa-шной сессией из сервисов? В том, что у нас вместо

> List result = dao.findByName(name);

в хибере именно так и сделано. плюс магия "связывания" интерфейса с запросом.

у нас (в одном из проектов):

List<MyUser> result = myUserDAO.findByName(name);

hibernate config: <query id="MyUserDAO_findByName" > FROM myUser u WHERE u.name = name </query>

Средсвами БД, если таковые поддерживаются. Java-кластеризация - штука очень специфическая. И не так то просто понять, как от неё добиться приличной производительности.

>> List result = em.createNamedQuery("Something.byName").setParameter("name", name).getResultList();

> Типичная ООП-жесть. Для простейшей выборки уйма телодвижений.

это не ООП, это отсутствие ВСТРОЕННОГО языка доступа к данным. Приходится делать ООП-"обертку".

Но это не обязательно тот же LINQ встроен в ООП язык C#.

>Поделия типа ScalaQL не нужны.

LINQ очень полезен для того, чтобы можно было отслеживать соответствие текстов запросов в DAO-слое модели данных. С помощью рефакторинга, например. Очень-очень облегчает жизнь, когда запросов очень много.

>LINQ очень полезен для того, чтобы можно было отслеживать соответствие текстов запросов в DAO-слое модели данных.

Опять 25. DAO != DAL. DAO используется только при процедурном подходе к описании БЛ (я обычно его и использую).

>тормозы и не поняли, что такое LINQ

А что такое LINQ?

>Посмотрите на типичные проекты на основе hibernate. Обычно это

Посмотрите на типичные поделия на Delphi. Обычно это форма TForm1 с брошенным на нее гридом TGrid1 и несколко обработчиков TButton1, TButton2, ...TButtonN

>Я лучше налабаю на коленке быдло-код с sql-ем

А в Delphi 2010 http://etnaweb04.embarcadero.com/news/press_releases/Delphi_2010_with_Touch_a... и лабать ничего не нужно, уже само все искаробки программирует. А ты знай только пиво подливай.

Да я и не спорю. Просто в "нормально спроектированной" "архитектуре данных" тексты запросов к БД скрыты за кучей фасадов. Но они есть. Будь то HQL или SQL или еще что, при при каждом обновлении базы (система вразработке) нужно будет оббегать десяток разработчиков и спрашивать "я вот хочу эту сущность двинуть туда-то, это у тебя ничего не поломает?". Если запросы охвачены рефакторингом, то такие вещи отлавливаются на автомате.

А всё остальное типа DAL, DAO, EAO,..., XYZ - это выбор позы для секса в гамаке. Всё равно в итоге извращение получается, как не крути. Да еще и тормозно. Я всеми этими делами года 4 назад перестал интересоваться ибо нефик голову захламлять.