Вдогонку: обычно то, что аннотированно Entity зовётся сущностью, а не SessionBean'ом, и его название схоже с именем таблицы (в данном случае, просто Session). Session-бином обычно обзывают класс, содержащий бизнес-логику. А чтобы быть бином, классу достаточно просто иметь конструктор по-умолчанию, откуда взялись ещё 2 условия, непонятно.
Для DAO обычно создаётся абстрактный generic-класс, в котором реализована большая часть кода (потому что для разных сущностей он фактически одинаковый). Судя по отсутствию в классе NEXEntityDAO слова extend, и наличию аннотаций Override, смею предположить, что код вставился криво и этот класс где-то есть, но не тут.
Ну и использовать нетипизированные запросы — плохо. Есть же TypedQuery
В сети таких туториалов огромная куча. Ещё там обычно тестовый проект прилагается, чтобы новичок (на которого рассчитана такая статья) мог пощупать проект. Не описано, как подключить БД к приложению: можно ведь через xml-конфигурацию (которых тоже несколько видов — persistence.xml, orm.xml), а можно и в классе всё настроить. А ещё можно не использовать конкретную реализацию JPA-провайдера, а использовать ту, что предлагает сервер приложений и соединение с БД настроить на нём.
Нет листинга HibernateUtil, который вроде как в коде присутствует.
Рассказал бы лучше про Lazy Loading и как с ней бороться, каскадности там всякие, преимущества Hibernate перед просто спецификацией JPA.
Нет, модели отправляют события в MVC. Модель предоставляет интерфейс для добавления слушателей на свои события. А подписан на них кто-то или нет — модели всё равно, она ничего не знает, кто и как будет использовать её данные дальше. Когда данные изменились, модель оповещает всех, кто подписался на её события. Паттерн Observer.
В MVP же прямой коммуникации между M и V нет, между ними посредник — P. Модель обычно пассивная и предоставляет только интерфейсы для манипуляции данными (сохранение, получение). V перенаправляет команды, поступившие от пользователя к P. P как-то на них реагирует, например, запрашивает данные у M. M выполняет полученные действия, отдаёт данные (если необходимо) обратно в P, P подготавливает их для отображения и отсылает к V.
Там получается такая схема: V<->P->M
Так это уже получается MVP. В классическом MVC контроллер обрабатывает события, поступающие от View и вызывает методы моделей. А модель рассылает оповещения (но подписываться на них должны сами View).
Как-то не совсем понятно, что хотел донести автор и какие выводы из всего этого должен сделать студент и прочитавшие.
Если это попытка показать, как выглядят программы на разных языках, то задача для этого выбрана совсем уж простая. Чтобы «прочувствовать» язык, надо написать что-то покрупнее, например веб-сервис или игру. А потом сравнить, какой из языков больше подходит к какой нише (хотя это и так все знают).
Если это сравнение скорости языков, то тут тоже огромное количество вопросов. Про вссемблер уже и так много сказано, могу добавить замечания по другим языкам.
1) Почему реализация питона только одна, если уж сравнивать на скорость, то надо было включить ещё и pypy? Он очень шустрый и довольно хорошо совместим с CPython. Например, у меня 33-е число Фибоначчи после прогрева pypy считает в 3-4 раза быстрее CPython.
2) Почему нет другого «гонщика» — luajit? У неё, например, в комплекте есть поддержка ffi, поэтому скорость на простых бенчмарках на уровне v8/java/pascal (у меня на машине у luajit и C почти одинаковое время).
3) Даже если забыть, что такую древовидную рекурсию обычно не используют в жизни, а стараются заменить её на что-то более линейное), всё равно так код не пишут. Например, хоть я и не писал на перле, но помню, что там есть такая замечательная штука, как memoize. Из таблицы видно, что перл уступает, например, питону. Но если добавить пару строк…
Но если добавить пару строк
use Memoize;
sub fib {
my $n = shift;
if ($n < 3) {return 1;}
return fib($n-1) + fib($n-2);
}
memoize('fib');
print fib(33), "\n"
Результаты:
$ time perl fib.pl
3524578
real 0m3.437s
user 0m3.427s
sys 0m0.008s
$ time perl fib-memo.pl
3524578
real 0m0.028s
user 0m0.020s
sys 0m0.008s
Это быстрее, чем PyPy (0m0.453s), Luajit(0m0.063s), и С без оптимизации (0m0.040s),
C -O3 одинаково.
Т.е. прирост в скорости составил 122 раза!
Но самое главное, что все эти выводы никак не применимы в реальной жизни. Никто не бросится переписывать всё с С на перл, потому что в бенчмарке они по скорости одинаковы. А вот для научных расчётов, например, люди любят использовать питон, несмотря на его неторопливость. Весь секрет в том, что на питоне там ничего не считается, это всего лишь удобная оболочка к фортрановским и сишным библиотекам.
Сравнивать веб-серверы под нагрузкой, это одно, там хотя бы задача приближена к реальности. А в этом примере, на мой взгляд, нет ни смысла, ни пользы.
Вот что ответили на этот счёт. В двух словах — Groovy ещё не в инкубаторе, нужно дождаться результатов голосования (хотя все считают, что оно будет положительным), поэтому даже про него рано говорить. А Grails даже не подавали заявку. И его судьба зависит от людей, которые его разрабатывают, поэтому лучше задавать эти вопросы в сообществах. Лично я не слежу именно за Grails, поэтому ничего не могу сказать, что с ним будет.
Для DAO обычно создаётся абстрактный generic-класс, в котором реализована большая часть кода (потому что для разных сущностей он фактически одинаковый). Судя по отсутствию в классе NEXEntityDAO слова extend, и наличию аннотаций Override, смею предположить, что код вставился криво и этот класс где-то есть, но не тут.
Ну и использовать нетипизированные запросы — плохо. Есть же TypedQuery
Нет листинга HibernateUtil, который вроде как в коде присутствует.
Рассказал бы лучше про Lazy Loading и как с ней бороться, каскадности там всякие, преимущества Hibernate перед просто спецификацией JPA.
На правах рекламы — моё демо-приложение, использующее JavaEE, JPA и JAX-RS (и WildFly). И небольшое описание toster.ru/q/207938#answer_563870
В MVP же прямой коммуникации между M и V нет, между ними посредник — P. Модель обычно пассивная и предоставляет только интерфейсы для манипуляции данными (сохранение, получение). V перенаправляет команды, поступившие от пользователя к P. P как-то на них реагирует, например, запрашивает данные у M. M выполняет полученные действия, отдаёт данные (если необходимо) обратно в P, P подготавливает их для отображения и отсылает к V.
Там получается такая схема: V<->P->M
Если это попытка показать, как выглядят программы на разных языках, то задача для этого выбрана совсем уж простая. Чтобы «прочувствовать» язык, надо написать что-то покрупнее, например веб-сервис или игру. А потом сравнить, какой из языков больше подходит к какой нише (хотя это и так все знают).
Если это сравнение скорости языков, то тут тоже огромное количество вопросов. Про вссемблер уже и так много сказано, могу добавить замечания по другим языкам.
1) Почему реализация питона только одна, если уж сравнивать на скорость, то надо было включить ещё и pypy? Он очень шустрый и довольно хорошо совместим с CPython. Например, у меня 33-е число Фибоначчи после прогрева pypy считает в 3-4 раза быстрее CPython.
2) Почему нет другого «гонщика» — luajit? У неё, например, в комплекте есть поддержка ffi, поэтому скорость на простых бенчмарках на уровне v8/java/pascal (у меня на машине у luajit и C почти одинаковое время).
3) Даже если забыть, что такую древовидную рекурсию обычно не используют в жизни, а стараются заменить её на что-то более линейное), всё равно так код не пишут. Например, хоть я и не писал на перле, но помню, что там есть такая замечательная штука, как memoize. Из таблицы видно, что перл уступает, например, питону. Но если добавить пару строк…
Результаты:
Это быстрее, чем PyPy (0m0.453s), Luajit(0m0.063s), и С без оптимизации (0m0.040s),
C -O3 одинаково.
Т.е. прирост в скорости составил 122 раза!
Но самое главное, что все эти выводы никак не применимы в реальной жизни. Никто не бросится переписывать всё с С на перл, потому что в бенчмарке они по скорости одинаковы. А вот для научных расчётов, например, люди любят использовать питон, несмотря на его неторопливость. Весь секрет в том, что на питоне там ничего не считается, это всего лишь удобная оболочка к фортрановским и сишным библиотекам.
Сравнивать веб-серверы под нагрузкой, это одно, там хотя бы задача приближена к реальности. А в этом примере, на мой взгляд, нет ни смысла, ни пользы.