|
|
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Допустим, мы пишем блогхостинг. Есть таблица юзеров и таблица постов. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Пост называется топовым, если viewcount>10000. Как мне с использованием хибернейта реализовать такую функциональность: 1)Проверить, если ли у данного пользователя хотя бы один топовый пост. 2)Получить список 10 последних (по дате) топовых постов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:10:55 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ, это провокация? Покажи как пытался решить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:15:28 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ1)Проверить, если ли у данного пользователя хотя бы один топовый пост. 2)Получить список 10 последних (по дате) топовых постов. А какие сложности? Хоть на HQL, хоть на Criteria API. Если вы себе SQL запросы представляете, то конвертировать их очень просто. Единственное что order by для огромной выбороки данных, штука стремная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:16:19 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
А какие сложности? Сложность в повторном использовании. Фаулер рекомендует rich domain model. В Rich domain model надо писать так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Но если я так сделаю, я потом не смогу переиспользовать логику, реализованную в методе isTop в sql запросах. Поэтому мне придется копипастить "viewcount > 10000" в каждый sql запрос. Потом, если вдруг критерии топовости поста поменяются, мне придется бегать по всему проекту и переписывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:40:56 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
это провокация? Разумеется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:41:53 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪНо если я так сделаю, я потом не смогу переиспользовать логику, реализованную в методе isTop в sql запросах. sql запросы, это всегда дублирование по отношению к доменной логике. Т.е. выше утверждение не верно. Нужно стремится повторно использовать БЕЗ sql запросов. А запросы оставить для аналитики и группировки\агрегации. Т.е. что ещё против твоего варианта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:46:43 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
sql запросы, это всегда дублирование по отношению к доменной логике. Если всю логику запихнуть во вьюхи, то нигде никакого дублирования не будет. Нужно стремится повторно использовать БЕЗ sql запросов. Без SQL запросов можно сделать очень мало чего. Например, вот это 2)Получить список 10 последних (по дате) топовых постов. нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:52:09 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ, 1. Я тебя понимаю, но мы же тут не обсуждаем конкурента (без ОРМ). Нельзя усидеть на 2-х стульях - либо ОРМ, либо твои вьюхи. 2. Дублирования нет и в DAO 3. Вопрос - "последние" не относится к первому вопросу, т.к. это аналитика. Её на SQL делать проще и можно. Итого: не мешай 2-3 вопроса вместе в один сабж. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:56:59 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
если проще, вьюха = DAO, но для аналитики возможностей меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:57:55 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪБез SQL запросов можно сделать очень мало чего. Например, вот это 2)Получить список 10 последних (по дате) топовых постов. нельзя. Почему нельзя? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 17:58:30 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪСложность в повторном использовании. Фаулер рекомендует rich domain model. В Rich domain model надо писать так: Rich Domain слишком обширное понятие. Фаулер рекомендует не попасть в ловушку Anemic Model, когда у вас вообще вся логика будет в сервисах, даже когда ей место в сущностях. Йуный джавистЪНо если я так сделаю, я потом не смогу переиспользовать логику, реализованную в методе isTop в sql запросах. Поэтому мне придется копипастить "viewcount > 10000" в каждый sql запрос. Потом, если вдруг критерии топовости поста поменяются, мне придется бегать по всему проекту и переписывать. Любая проблема решается внедрением дополнительного абстрактного слоя: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 18:11:10 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ, как-то так. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 18:39:56 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
а если в будущем топовость поста будет определяться не только свойствами класса Post, а например еще чем-то (популярность автора например)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 21:15:01 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Любая проблема решается внедрением дополнительного абстрактного слоя: Я такого ответа и ожидал - это единственный способ писать код с хибернейтом и не насиловать базу. Но при этом получается, что эти критерионы - это в принципе те же самые вьюхи, только для Hibernate. При этом они намного менее читабельны. HQL никак не комбинируется с критерионами. Возникает вопрос, зачем тогда вообще нужен хибернейт, если логику писать на нем неудобно. Не легче ли всю логику сделать на вьюхах и потом тупо перегонять резалтсеты в Value Objects? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 21:42:32 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪВозникает вопрос, зачем тогда вообще нужен хибернейт, если логику писать на нем неудобно. Не легче ли всю логику сделать на вьюхах и потом тупо перегонять резалтсеты в Value Objects? - у хибера узкая область - CRUD. - зачем перегонять в VO? Проще резалтсет сериализовать - вы сторонник Одного подхода? Я - нет. Что-то должно конкурировать с резалтсетами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 21:50:51 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Единственное что order by для огромной выбороки данных, штука стремная. В данном конкретном случае топовых постов должно быть намного меньше, чем общее число - на то они и топовые. Можно сделать для них partial index по дате. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 21:51:38 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
chpashaа если в будущем топовость поста будет определяться не только свойствами класса Post, а например еще чем-то (популярность автора например)? точно так-же как в БД - Join, тут вместо него - доп.бизнес-слой. Никакой магии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 21:52:27 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪЯ такого ответа и ожидал - это единственный способ писать код с хибернейтом и не насиловать базу. Нет, не единственный. Никто не парится с тем чтобы хранить критерии в DAO и только когда нужно, то выности их на более верхние слои. Йуный джавистЪНо при этом получается, что эти критерионы - это в принципе те же самые вьюхи, только для Hibernate. Хибернейт здесь не при чем. Эти критерии можно транслировать и в HQL и в SQL при надобности. Йуный джавистЪПри этом они намного менее читабельны. HQL никак не комбинируется с критерионами. Это проблема Java синтаксиса, а не ORM. Йуный джавистЪВозникает вопрос, зачем тогда вообще нужен хибернейт, если логику писать на нем неудобно. Экономит массу времени на реализации CRUD, каскадов и пр. Йуный джавистЪНе легче ли всю логику сделать на вьюхах и потом тупо перегонять резалтсеты в Value Objects? View работает с табличными данными. Менеджить ветвистые иерархии на них сложнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 21:54:28 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Petro123chpashaа если в будущем топовость поста будет определяться не только свойствами класса Post, а например еще чем-то (популярность автора например)? точно так-же как в БД - Join человек хочет стратегию топовости написать ровно один раз. join придется повторять кучу раз для похожих запросов. или написать вьюху, как хочет топикстартер. лично я так и сделал бы. вряд ли будет проблемой перенести ее в другую БД если завтра война. так хуле мучатся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 22:31:58 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
chpasha, ну, я рассматриваю 2 технологии, как параллельные - для простоты: - Не ORM (1 раз во вьюхе\триггере\ХП) - ОРМ (1 раз в DAO\тут тоже 2-3 варианта) Т.е. варианты есть всякие. Особых проблем по сабжу нет. Пусть пишет как нравится :) imho ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 22:39:10 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
В общем, есть два способа: Первый: Код: sql 1. 2. 3. Второй: Код: sql 1. 2. 3. 4. Первый является непомерным злом, так как провоцирует писать такой код: Код: sql 1. 2. 3. Второй способ - это SQL программирование, только сильно извращенное - код мало читабелен, урезаны родные возможности СУБД, нет проверки в compile time. В обоих случаях получается, что бизнес логики на ООП не бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 23:06:34 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Petro123- Не ORM (1 раз во вьюхе\триггере\ХП) imhoлично мне не очевидно, почему одно исключает другое. если задачу можно решить более эффективно (в ущерб портируемости, когда это допустимо) , то почему-бы и нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2012, 23:48:06 |
|
||
|
Повторное использование кода в Hibernate
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪВторой способ - это SQL программирование, только сильно извращенное - код мало читабелен, урезаны родные возможности СУБД, нет проверки в compile time.если не нравится Criterion - используйте SQL или HQL. Есть среды разработки (IDE) которые умеют Hibernate и JPA валидировать по базе. compile-time проверка есть в случае использования JPA Criteria API, но ИМХО это на сильного любителя. Уж больно многословно. Йуный джавистЪВ обоих случаях получается, что бизнес логики на ООП не бывает. Джавист видать подрос, раз такие оценки выдает на раз Предлагаю для того, чтобы все прониклись идеей сузить ваш вывод - "получается, что бизнес логики на Java не бывает." ;))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2012, 00:07:06 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=37712216&tid=2132280]: |
0ms |
get settings: |
17ms |
get forum list: |
20ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
66ms |
get topic data: |
19ms |
get forum data: |
5ms |
get page messages: |
112ms |
get tp. blocked users: |
2ms |
| others: | 351ms |
| total: | 604ms |

| 0 / 0 |
