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

s/заменять/заменить/ ?

s/ассиметричный/ассимметричный неучи ёпта

очевидное решение учитывая как компилится for.

Наконец то до людей доходит, насколько по-уродски выглядит работа с реляционными данными в ООП-стиле.

> ".edu" - домен - LOL! :)))

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

Кадры похоже просто тормозы и не поняли, что такое LINQ
Но назквание Скалка, это прикольно :)

>Наконец то до людей доходит, насколько по-уродски выглядит работа с реляционными данными в ООП-стиле.
И чем вам не нравятся те-же хибернэйт и ибатис?(кроме названия)

s/ассимметричный/асимметричный неучи ёпта

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

меня давно интересует другой вопрос- кому нужно это монстрообразное поделие Hibernate, если есть мегарулезный JDBC

По традиции из текста новости не понятно что это и для чего.

Подробности удручают... Найти не пдф не удалось.

Это ж просто research paper. Где сама библиотека-то?

А было бы хорошо, да. Scala — это то, чем должна была быть джава изначально.

некоторые ограничения "напрягают"

>И чем вам не нравятся те-же хибернэйт и ибатис?(кроме названия)

А тем что никто толком не знает как это правильно применить. Посмотрите на типичные проекты на основе hibernate. Обычно это сочетание двух анти-паттернов: Anemic Domain Model, ну вы знаетете, это такие дибильные java-модельки аля набор полей и геттеы/сеттеры для доступа к ним и никакой бизенс логики и анти-паттерна Hibernate Session per Dao action. Это когда мы запихиваем session в убогую оболочку DAO, которая превращает собственно ORM-меппинг в простое отображение записей из бд в коллекцию тех самых дурацкий объектов-наборов полей. С другой стороны не используй мы DAO, лишаемся возможности абстрагироваться от реализации DAL. Но вы часто меняете DAL?

Вывод - бизнесс-логику моделируем в полноценных сущностях а в Service Layer с помощью Hibernate Session управляем ORM-отображением, получая массу удовольствия от весьма и весьма сложного поведения session. Чешем в затылке, забиваем на все это безумие с ORM и пишем JDBC внтури service-методов. Profit!

>> И чем вам не нравятся те-же хибернэйт и ибатис?(кроме названия)

> А тем что никто толком не знает как это правильно применить.

Сейчас тебе скажут, что только ты не умеешь их применять :)

>Чешем в затылке, забиваем на все это безумие с ORM и пишем JDBC внтури service-методов. Profit!

Кто мешает писать на Hibernate внутри сервис-методов? Нахрена надо изобретать дополнительный DAO слой?

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

> меня давно интересует другой вопрос- кому нужно это монстрообразное поделие Hibernate, если есть мегарулезный JDBC

А меня давно интересует другой вопрос- кому нужно это монстрообразное поделие С, если есть мегарулезный ассемблер.

Вы либо тролль, либо ничего, сложнее "Hello, world!" на Джаве не разрабатывали.

>Кто мешает писать на Hibernate внутри сервис-методов?

Ну дык я только что написал что мешает, хотя это вроде и правильно.

"Вывод - бизнесс-логику моделируем в полноценных сущностях а в Service Layer с помощью Hibernate Session управляем ORM-отображением, получая массу удовольствия от весьма и весьма сложного поведения session."

ORM в целом технология сложная и спорная. Чем больше пытаешся сделать "по уму" тем больше набиваешь шышек. Если есть желание и куча времени, читай бюджета, играться с прихотями сессий и кешей, то пожалуйста, вперед. Я лучше налабаю на коленке быдло-код с sql-ем и пойду пить пиво.

>Нахрена надо изобретать дополнительный DAO слой?

Я вот тоже не знаю нахрена. Но так пишут. Видимо привычка. А в Spring например это (DAO) основной метод работы с БД.

У Вас очень умные мысли, поток сознания, который мне, простому смертному, недоступны.

Ответьте мне, жалкому кодеришке на простой вопросик, а то спать не буду:

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

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

Это будем делать на hibernate. Только не рассказывайте сказки про мега-задачи каждый божий день, я сам жабщик и многих повидал. Подавляющее большинство пишет унылые дергалки БД без всяких заморочек. Если у вас действительно сложные и интересные задачи, где без таких готовых комплексных решений как hibernate не обойтись, я только рад за вас. Я же говорю о простых смертных java-быдлокодерах.

Не чего лукавить про "сложность хайбернейта".

Для спринга достаточно указать в конфиге вместо JDBC

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:lang="http://www.springframework.org/schema/lang"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                           http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd
                           http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
                           http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
                           http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang-2.0.xsd"
>

<!-- ... -->

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
	  <property name="driverClassName" value="org.hsqldb.jdbcDriver"/>
	  <property name="url" value="jdbc:hsqldb:mem:."/>
	  <property name="username" value="sa"/>
	  <property name="password" value=""/>
    </bean>

    <bean id="genericJdbcDao" abstract="true" class="org.springframework.jdbc.core.support.JdbcDaoSupport">
        <property name="dataSource" ref="dataSource"/>
    </bean>

    <bean id="myTableDao" class="dao.MyTableDaoImpl" parent="genericJdbcDao"/>

<!-- ... -->

</beans>

Для хибера примерно так будет

    <bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
	  <property name="driverClassName" value="org.hsqldb.jdbcDriver"/> 
	  <property name="url" value="jdbc:hsqldb:mem:."/>
	  <property name="username" value="sa"/>
	  <property name="password" value=""/>
    </bean>

    <bean id="mySessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
      <property name="dataSource" ref="myDataSource"/>
      <property name="mappingResources">
        <list>
          <value>model/MyClass.hbm.xml</value>
        </list>
      </property>
      <property name="hibernateProperties">
        <props>
          <prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect</prop>
          <prop key="hibernate.hbm2ddl.auto">update</prop>
        </props>
    </property>
  </bean>


  <bean id="myClassDao" class="dao.ClassDaoImpl">
    <property name="sessionFactory" ref="mySessionFactory"/>
  </bean>


Что здесь сложно?

Да, и, кстати, с транзакциями никаких проблем

<tx:annotation-driven transaction-manager="txManager" />

<bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory" ref="mySessionFactory" /> </bean>

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

Это "изобретение велосипеда из руды" (с).

> С другой стороны не используй мы DAO, лишаемся возможности абстрагироваться от реализации DAL. Но вы часто меняете DAL?

на проектах меняется часто (для проекта) - раз в несколько лет. + DAO упрощает написание сервисов. Сервисы содержат только бизнес-логику, а DAO только логику CRUD.

> Чешем в затылке, забиваем на все это безумие с ORM и пишем JDBC внтури service-методов.

вот от мега-решений на чистом JDBC это такой мега-фарш на DAO уровне. И это всего лишь разрабатывали приложение работающее поверх 2-х СУБД. Когда топ-менеджеры узнали во сколько встанет добавить еще одну СУБД, то пришли в ужос.

В общем ORM это хрень, но JDBC это просто ужос. Возможно спас бы SQLJ, но природе оно не встречается :(

PS для нового проекта выберу ORM.

>Что здесь сложно?

Сложного здесь ничего. Но это не совсем корректно.

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

В итоге сделав корректно получаем довольно таки нетривиальное решение. Игра стоит свечь, если она действительно того стоит=).

> меня давно интересует другой вопрос- кому нужно это монстрообразное поделие Hibernate, если есть мегарулезный JDBC

Петросян.jpg

>> Нахрена надо изобретать дополнительный DAO слой?

> Я вот тоже не знаю нахрена. Но так пишут. Видимо привычка. А в Spring например это (DAO) основной метод работы с БД.

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

> Anemic Domain Model

Это НЕ антипаттерн. Не каждая модель имеет поведение, меньше Фаулера слушать надо.

Посмотрите, в указанной Вами странице дается решение (по ссылке переход), как создать перехватчик.

> Я лучше налабаю на коленке быдло-код с sql-ем и пойду пить пиво.

но пиво придется пить на рабочем месте пока борешься с багами... или изобретать свой лисапед который понимает, что в Oracle нет boolean типа, а в PostgreSQL есть. Потому при проверке на private boolean status; в Oracle нужно писать status == 1, а в PSQL status == true.

В итоге этот лисапед приходится постоянно развивать, а это намного сложнее чем использовать Hibernate.

>Не каждая модель имеет поведение,

Увы, тогда это не модель. Модель что-то моделирует. Что моделирует набор полей? Строку в БД? Тогда вполне достаточно чего-то вроде List<Map<String, Object>> на выходе dao. И вполне достаточно JDBC.

Да, а, кстати, что бы Вы-таки нам уже имеете сказать за AOP?

На theserverside статья была про AOP+DTO. Можно погуглить.

> Увы, тогда это не модель. Модель что-то моделирует. Что моделирует набор полей? Строку в БД? Тогда вполне достаточно чего-то вроде List<Map<String, Object>> на выходе dao. И вполне достаточно JDBC.

Модель моделирует domain. Domain это разного рода сущности, с поведением или без.

>> Не каждая модель имеет поведение,

> Увы, тогда это не модель. Модель что-то моделирует.

это модель данных. Но не каждая модель данных имеет модель поведения В ДАННОМ КОНКРЕТНОМ СЛУЧАЕ бизнес-функций.

Увы, у нас с вами разные места работы. Видели кода-нибудь SQL-запрос длиной в 300-400 строк? Там замуты похлеще boolean. Видели работы с иерархиями и как они реализованы в разных СУБД. В таких случаях ни о каком ORM не может идти и речи. Нужно оталкиваться от того как мы моделируем область. Если отталкиваемся от схемы БД, то о ORM забыть можно точьно. Так же можно и забыть о смене DAL. Это нереально.

>В итоге этот лисапед приходится постоянно развивать, а это намного сложнее чем использовать Hibernate.

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

> Видели кода-нибудь SQL-запрос длиной в 300-400 строк

Видел-ведел. Это типичный антипаттерн от олдфаговых оракл БД-админов.

> хибернейт часто применить либо избыточно, либо нереально

Слишком категоричное утверждение.

Если у Вас задачи с сессиями, то решение описано. В EJB 3.0 "проблема с DTO" отпала.

> Это типичный антипаттерн от олдфаговых оракл БД-админов.

В точку, иногда такая жесть попадается, что смотреть страшно. X_X

>Если у Вас задачи с сессиями, то решение описано.

Описано-то оно описано. Но как говориться не в коня корм. Сложновато это и для меня и для моих коллег, да и для многих кого знаю. Знаю, сами виноваты.

>Видел-ведел. Это типичный антипаттерн от олдфаговых оракл БД-админов.

Угу, точна точна)) Но эти олдфаги к сожелению многое решают.

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

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

List result = dao.findByName(name);

будет

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

Вторая строчка конечно подлиннее будет, но имхо это меньшее зло, нежели плождение кучи лишних сущностей.

> Что здесь сложно?

Ты действительно собрался конкурировать *этим* LINQ to SQL, который понятен пятиклассникам?

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

Во-первых, это вообще научная статья, а их для другого пишут %)

Во-вторых, ответ LINQ был бы полезен для уменьшения уровня вхождения и простых задач. На мой взгляд.

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

Ну смотри.

Допустим у нас есть сущности Entity1, Entity2, Entity3. Для каждой сущности свой DAO - Entity1Dao, Entity2Dao, Entity3Dao (интерфейсы и реализации).

В аппликухе может быть много сервисов (я про Service-layer сейчас) с так называемой бизнес логикой. Когда есть слой DAO, я делаю @Autowired Entity1Dao entity1Dao и юзаю его в сервисе. Этот же DAO может использоваться ещё в десятках сервисов. Итого ты предлагаешь закопипастить методы DAO по сервисам, тем самым размазав слой DAO по Service-layer и смешать пресловутую бизнес логику с data access?

И между прочим не все методы DAO такие простые, как dao.findByName(name). Плюс DAO не завязан исключительно на базу данных, мало ли к чему он там обращается (web service (буэээ, но всё же), какой-то REST-style API и т.п., те же XML-ки (почему нет - ынтырпрайз же) ну и JPA/Hibernate/whatever).

> Вторая строчка конечно подлиннее будет, но имхо это меньшее зло, нежели плождение кучи лишних сущностей.

DAO - это не лишняя сущность, может, у тебя пока просто недостаточно опыта для понимания этого...

> , который понятен пятиклассникам

Как толсто! Вы пятиклассник? Тогда для Вас троллинг в разделе Talks.

Я привык обосновывать, аргументировать на примерах свои сентенции. Иначе - все это просто слова.

> а их для другого пишут

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

Кстате, помница я уже читал срачь на эту тему (hibernate + DAO):

http://www.theserverside.com/news/thread.tss?thread_id=40581

Аргументов в пользу DAO можно привести ещё много:

* возможность отдельно тестировать business logic и data access
* возможность легко подменить реализацию для data access
* когда есть DAO, код сервиса становится _ПРОЩЕ_ и читабельней
* повторное использование кода для data access - о чём я писал выше
* в конце концов разные люди могут бацать DAO и Service Layer
* ... etc

>Аргументов в пользу DAO можно привести ещё много:

Моя ложка дегтя: не совсем корректо использовать DAO с Hibernate (ну или что у вас там JPA etc), аргумент из того срача с серверсайд который мне больше всего понравился- вместо DAO (Data Access Object) для Hibernate нужно что-то вроде EAO (Entity Access Object), который умеет делать не CRUD, а PRADR (Persist, Retrieve, Attach, Detach, Remove) Аргумент от батька фаулера =) - DAO (тобишь Table Dada Gateway) должен возвращать не сущности, а данные таблицы. Подход широко используется во вражеском лагере - ADO.NET.

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

Мое уважение к жабщикам стремительно растет - нужно иметь мозги, чтобы запомнить такую кучу аббревиатур %)

>DAO - это не лишняя сущность, может, у тебя пока просто недостаточно опыта для понимания этого...

У меня слишком много негативного опыта работы с ними. Иногда конечно полезно вынести работу с данными в отдельный бин (например когда у нас возможна ситуация записи не в базу, а куда-нить еще, в те-же веб-сервисы или через jms какой-нить xml отослать), но в огромном количестве случаев это owerkill, ведущий к тому что бизнес-операци: получить данные от клиента, провалидировать их, добавить какую-то служебную информацию и записать все это в базу - разносится по куче бинов, да еще и в разных подпроектах.

Я не против самой идеи DAO, я против того, чтобы не думая пихать их куда не надо, что очень часто происходит в реальных проектах.

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

АСИММЕТРИЧНЫЙ

в школу.

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

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