Выполнять руками большой объем работы который может быть автоматизирован это конечно г0внокодинг. Но тут надо понимать разницу между: простыми DTO генерируемыми JPublisher-ом и няшными самописными Business Objects, в которых все сделано по уму, инкапсуляция, целостность, бизнес логика и т.д. Перекладывать руками из процедуры в plain DTO смысла не много. А вот создавать Business Objects с которыми потом приложение может полноценно работать, это совсем другое.



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



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

В этом, пожалуй, заключается одно из основных преимуществ реализации логики работы с данными на стороне СУБД. Изменил спецификацию таблицы, все связанные объекты ревалидирутся, ошибки всплывают сразу и без юнит тестов. Привыкнумши к этому однажды, необходимость отвыкать обратно при переходе на другую платформу, сложно воспринимать иначе как откровенный дауншифт.


Я так полагаю подобный автоматически генерируемый код должен бы регенерироваться  билд сценарием. Согласись, это было бы очень здорово. При изменении схемы данных, при изменении спецификации серверных процедур, ошибки вылазили бы еще на этапе сборки. Допиливание напильником полностью нивелирует данный профит. Тут допустимо только наращивание костылей сверху. В моем случае так, увы, не получится - полученный врапер не работоспособен в принципе. Он закрывает стайтмент внутри функции, что влечет за собой и закрытие возваращаемого курсора. Сейчас хочу попробовать врапнуть PL/SQL пакет другим PL/SQL пакетом который будет иметь спецификацию, которую JPublisher сможет врапнуть корректно. Пока - не получается.

К слову, справедливости ради, надо отметить, что врапперы от DOA Package Wizard, таки тоже местами приходилось допиливать напильником. Помню, давно-давно, когда я еще писал на делфи, а не в песочницу, и о винграде вообще слыхом не слыхивал, в каком-то форуме, где обсуждались проблемы работы этого визарда, затесался какой-то жава девелолопер и с очень обидным пафосом и опломобм изрек бла-бла вроде "не стоит сравнивать велосипеды с иномарками, на велосипед, как ни крути, кондиционер не приспособишь". Сейчас, имея более близкое знакомство с технологиями Жавы нежели тогда, я бы уже не затаил бы обиды, а преисполнился бы иронией к автору этой сентеции.

Это сообщение отредактировал(а) Zloxa - 10.2.2012, 14:37

Гугл подводит. Не окажите ли услугу дать прямой линк?

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

В то же время жава имеет куда более очевидный тренд


В отличии от C#


здесь с-ка рост очевиден.
Не могу не похвалить себя. Когда еще в 2002м году я пролистал первую книжку по C#, я пришел к заключению, мол все мы там будем. (

Это сообщение отредактировал(а) Zloxa - 10.2.2012, 15:00

Да, конечно - http://en.wikipedia.org/wiki/Object-relational_mapping
В джаве самый популярный это Hibernate, в дотнете есть NHibernate и какой-то майкросовтовский фреймворк со словом Entity в начале.
Java да, тоже умрет когда-нибудь - что поделаешь. Однако ближайшие лет 10 джавистам беспокоиться не о чем.
Вон, делфи - сколько лет уже пребывает в агонии, однако программисты до сих пор умудряются программировать на нем  

Добавлено через 54 секунды

А буквы в ОРО русские, кстати. Объектно-реляционное отображение это расшифровывается. 

Посмотри на проблему шире. Ты смотришь на свой маленький кусочек: СУБД+около СУБД-шная логика. У любой более менее сложной системы есть внешние системы, которые так же могут поменять API и твое приложение перестанет работать, или наоборот они перестанут работать. Конечно если все делать в СУБД, то таких проблем можно избежать (да и то не всегда, не забываем про динамический SQL). Но такое решение выглядит, мягко говоря странным, не говоря уж про его реализуемость.



Особенно когда у тебя несколько баз для разработки и на каждую патчи по своему графику накатываются 





Ну тогда у С++ еще более печальная тенденция 

Ты просто неправильно расцениваешь эти графики.

Это скорее индикатор модности языка, чем реальное положение на рынке.

Добавлено через 4 минуты и 23 секунды
Вот еще один рейтинг.

Хороший рейтинг, да.

Я не понял мысли которую ты пытался сейчас донести.   
Следует сознательно отказаться от идеи организовать жесткую связь на уровне исходного кода между модулями в гетерогенной системе в пользу динамической связи, потому что шит вездесущ и всяко может хаппенс?   


Я подумал было, что это имя собственное ))


Будучи труЪ датабазником, когда я слышу это слово, я просто обязан уронить на пол кирпич   


Это сообщение отредактировал(а) Zloxa - 10.2.2012, 19:24

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

А какие для этого еще нужны аргументы?   
Может и жесткую типизацию - нуеганафиг? В пользу динамической типизации? Фигли, юнит тестами все вытестим.

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

Я высосал из пальца лишь три. И все три - не про оракл. Для каждого из трех кейсов, в динамическом связывании преимуществ не вижу.   

Динамической связывание, это следствие распределенности, а не самоцель.

провокация к г0внокодину детектед   

У вас детектор сломался  

Это просто вы уж принюхались, не замечаете