Есть JSF приложение. Необходимо добавить paging.
Решил создать PagebleController. В нем соответственно действия: nextPageAction и prevPageAction, и abstract getEntries.
Соответственно дети перекрывают метод getEntries. Дети отвечают за отображение сущностей различных типов.
И в getEntries происходит изменение pageCount и currentPageNumber. Буду рад любой критике. PS: I'm a newbie with JSF applications (=
Собственно сам вопрос:
Существует одна особенность — приложение должно сохранить свою переносимость с одного типа базы на другую.
Отсюда два выхода:
A. для каждой базы написать свои запросы и при запуске приложения в зависимости от кофига использовать тот или иной набор запросов.
B. глупо вытаскивать и забирать лишь нужное, максимум установить setMaxRows(int).
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, zubr, Вы писали:
Z>> Z>>Заранее благодарю. C>А может взять Hibernate и не мучаться? Там адаптеры для paging'а для каждой базы уже написаны.
Видимо так и придется сделать потому, что ничего умнее в голову не приходит.
Осталось посмотреть как у Hibernate дела обстоят с BLOB'ами.
Здравствуйте, zubr, Вы писали:
Z>Здравствуйте, Cyberax, Вы писали:
C>>Здравствуйте, zubr, Вы писали:
Z>>> Z>>>Заранее благодарю. C>>А может взять Hibernate и не мучаться? Там адаптеры для paging'а для каждой базы уже написаны. Z>Видимо так и придется сделать потому, что ничего умнее в голову не приходит. Z>Осталось посмотреть как у Hibernate дела обстоят с BLOB'ами.
Дела хорошо. http://www.hibernate.org/73.html
Вообще, не понимаю, почему люди так любят JDBC (или, как вариант, создание двухколёсных одноместных транспортных экипажей, приводимых в действие мускульной силой), если есть отлично оттестированная и отпрофилированная тулзень?? Вот цитата из Hibenate in Action:
Development of a reasonably full-featured ORM may take many developers months. For example, Hibernate is 43,000 lines of code (some of which is much more difficult than typical application code), along with 12,000 lines of unit test code. This might be more than your application. A great many details can easily be overlooked—as both the authors know from experience!
Ещё цитата:
A common claim is that hand-coded persistence can always be at least as fast, and can often be faster, than automated persistence. This is true in the same sense that it’s true that assembly code can always be at least as fast as Java code, or a handwritten parser can always be at least as fast as a parser generated by YACC or ANTLR—in other words, it’s beside the point.
....
Finally, the people who implemented your ORM software probably had much more time to investigate performance optimizations than you have. Did you know, for instance, that pooling PreparedStatement instances results in a significant performance increase for the DB2 JDBC driver but breaks the InterBase JDBC driver? Did you realize that updating only the changed columns of a table can be significantly faster for some databases but potentially slower for others? In your handcrafted solution, how easy is it to experiment with the impact of these various strategies?
Как по мне, если есть база и Жава, то по дефолту должен быть и ORM, и чтобы отказаться от ОРМ — нужны действительно серьёзные причины.
Здравствуйте, Gajdalager, Вы писали:
G>Вообще, не понимаю, почему люди так любят JDBC (или, как вариант, создание двухколёсных одноместных транспортных экипажей, приводимых в действие мускульной силой), если есть отлично оттестированная и отпрофилированная тулзень?? Вот цитата из Hibenate in Action:
Потому, что hibernate не панацея... если нет навороченной иерархии которую надо вытаскивать
за один главный объект, то надобность в hibernate невелика... если это отчеты сплошные
по datawarehouse, то там настолько критично становиться ручная оптимизация sql,
то hibernate становится тут пятым колесом... можно обойтись jdbc или на крайний случай
ibatis... Ну и еще приходится использовать jdbc для загрузки/выгрузки больших объемов данных,
а еще бывает что приходится пихать sql в таких случаях как этот http://rsdn.ru/Forum/Message.aspx?mid=2402473
и если таких пиханий больше чем персистентых объектов, то каков смысл использования хибера?
G>Как по мне, если есть база и Жава, то по дефолту должен быть и ORM, и чтобы отказаться от ОРМ — нужны действительно серьёзные причины.
Эти причины обычно возникают очень часто... к сожалению , т.к. RDBMS и OOP очень часто несовместимы...
Здравствуйте, Gajdalager, Вы писали:
G>Дела хорошо. http://www.hibernate.org/73.html G>Вообще, не понимаю, почему люди так любят JDBC (или, как вариант, создание двухколёсных одноместных транспортных экипажей, приводимых в действие мускульной силой), если есть отлично оттестированная и отпрофилированная тулзень?? G>Как по мне, если есть база и Жава, то по дефолту должен быть и ORM, и чтобы отказаться от ОРМ — нужны действительно серьёзные причины.
Иногда от него и не приходится отказываться , потому что изначально использовался JDBC.
А вот по поводу BLOB такой вопрос:
В базе будут хранится не только маленькие (about 1-16Kb) файлы, но и скорее всего большие (10-100Mb) хотя и в меньшем количестве. В качестве AS используется JBoss...
Здравствуйте, zubr, Вы писали:
Z>Здравствуйте, Gajdalager, Вы писали:
G>>Дела хорошо. http://www.hibernate.org/73.html G>>Вообще, не понимаю, почему люди так любят JDBC (или, как вариант, создание двухколёсных одноместных транспортных экипажей, приводимых в действие мускульной силой), если есть отлично оттестированная и отпрофилированная тулзень?? G>>Как по мне, если есть база и Жава, то по дефолту должен быть и ORM, и чтобы отказаться от ОРМ — нужны действительно серьёзные причины. Z>Иногда от него и не приходится отказываться , потому что изначально использовался JDBC. Z>А вот по поводу BLOB такой вопрос: Z>В базе будут хранится не только маленькие (about 1-16Kb) файлы, но и скорее всего большие (10-100Mb) хотя и в меньшем количестве. В качестве AS используется JBoss...
Это не проблема... с блобами можно работать как с InputStream/OutputStream...
Например запись данных в блоб по указанному смещению примерно так:
Здравствуйте, aka50, Вы писали:
A>Это не проблема... с блобами можно работать как с InputStream/OutputStream... A>Например запись данных в блоб по указанному смещению примерно так: A>
A> OutputStream outputStream = entity.getData().setBinaryStream(offset);
A> outputStream.write(data);
A> outputStream.close();
A>
Думаю пока что оставлю БЛОБы как есть — нативные SQL. А остальное сделаю в entity beans
, т.к. RDBMS и OOP очень часто несовместимы...
