Не множко рад, куда пошла тема - стало как-то добрее и меньше понтов, уж простите..
Просто БД всё-таки - это только часть системы, как бы она ни была важна, отсюда надо и плясать, и всё-таки не забывать основные принципы программирования и не пытаться объять необъятное..


Это лишь говорит, что хорошо бы объединить два подхода, чтоб каждый, вмеру своих сил занимался своим делом )


Мне кажется банально: когда НУЖНО! те есть необходимость.

JDBC и ORM я не сравниваю, жаль если я не смог донести мысль..

Если у вас в команде есть хороший специалист по Oracle, то остаётся стать специалистом по JEE    и всё будет  .

Знаете, DimW, можно сделать вывод, что у Вас проблемы с общением. Может быть, хватит обвинений в непрофессинализме, отсутсвии здравого смысла? Я говорил, что у меня есть опыт работы "с" Оракл, а не "в". И те небольшие приложения, в которых в одном месте делается  rollback, а в другом commit, я не могу назвать сколь-либо серьёзными, более того, в этих случаях можно было вообще обойтись без этого механизма. Серьёзная же система, использующая транзакции - совсем другое дело.

А если оно Read-only - только запрашивает информацию из БД?


Ключевые слова выделил. Вы сами допустили возможность, что он не оговорился, поэтому мне и интересно.


Мы не спецы, мы пока только учимся   

возьмите то, что хотели.. даже, если ваш проект загнётся, каждый из вас получит опыт для "продолжения" жизни   опыт с Hibernate, Spring, Velocity, Oracle не могут не пригодится по определению   только пишите слоями -> например, логика и web-презентация вместе не допустимы. попытайтесь всё сразу распределять на "уровни" и будет вам счастье    трах-тибидох-тибидах   

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

Почему чужому дяде ? Почему не искусство ? Главное выбрать нужный подход. А при правильном подходе программирование для вас будет искусством - источником получения удовольствия , да ещё и приносящее вам бабло. 


Для этого в разработке ПО и существует этап проектирования. А перед этапом проектирование есть этап разработки Технического Задание. Так вот руководствоваться при выборе подхода надо на основе ТЗ . 
Так что идти надо от цели , а субд , (gui/web)приложение должны разрабатываться с тщательностью в равной степени.


транзакции - это первостепенная задача в вашем приложении?

polosatij, по поводу слоёв хорошо написано в документации по Spring, да и в множестве других источников, именно так мы и строим проект. Что до стиля - да здравствует Java и рекомендованный Sun стиль написания кода на ней ;)


Транзакции, это не задача, тем более, не первичная, - это средство.


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

Это сообщение отредактировал(а) CaligoSpiritus - 26.9.2008, 23:20

переозвучу фразу: 
"научиться работать с транзакциями в контексте текущего приложения" - не первичная задача? 
это риторический вопрос, мне кажется, на данном этапе не стоит этому уделять внимание.


я тоже говорил о дизайне.

Или вы что то другое подразумевали под словом дизайн?

Это сообщение отредактировал(а) v2v - 26.9.2008, 23:44

Я об этом.
В общем, я с Вами согласен 


Этому нельзя не уделять внимание, потому что многие операции соц. сети обязаны быть транзакционными. В этом проекте довольно большая часть логики, в том числе и транзакционной, будет в СУБД, но и на App. Server кое-что придётся. Именно поэтому меня заинтересовало, как инструменты ORM framework-ов могут помочь. Хотя, в принципе, транзакционный механизм неплохо реализован в Spring и никаких особых трудностей не предвидится, этот мой вопрос больше из любопытства.

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



серьёзна?

1). моё бабло прямо пропорционально зависит от просиженных часов, т.к. оплата по часовая.
2). если ты долго в проекте и у него хорошо идут дела, тересна мне, как ты хочешь заняться искусством, если тебе каждая деталь уже давно известна и занимаешься "тупой" конвеерной работой



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


Это сообщение отредактировал(а) polosatij - 27.9.2008, 11:55

мне не понятен сарказм.

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


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

Это сообщение отредактировал(а) v2v - 27.9.2008, 12:07

не могу.. замкнутый круг.. грядут повышения в карьере и не хилый прирост заработной платы, есть свободный график и нормальный коллектив. да и сам заказчик очень доволен работой (стучу по столу), такое тоже не каждый раз бывает.. это держет меня по самые нехочу  
ничего, время покажет.. если совсем по перёк горла встанет, можно будет послать всё к чертям и ...   





я так и делаю   однако всё равно, сроки есть.. и по 14 часов в день в коде приходится копаться   

Это сообщение отредактировал(а) polosatij - 27.9.2008, 12:16

Давно не просматривал дискуссию. И хотя она, по моему мнению, далеко ушла от темы, хочется все же ответить на очередные обвинения в некомпетентности, воспоследовавшие в мой адрес.

Когда я говорил об управлении транзакциями, я имел в виду обеспечение выполнения множества семантически связанных SQL операций, когда атомарные операции собраны в достаточно репрезентативную группу (право стыдно об этом говорить), а вовсе не написание команд COMMIT или ROLBACK, как это кое-кто подозревает и, упаси боже, вовсе не попытку как то изменить в этой части поведение СУБД. При этом я имел в виду не только наборы DML операций, но и транзакции на чтение.

Если речь идет о  DML операциях, при их выполнении более или менее сложной группой у вас есть два выхода:
1.    Вручную писать специализированные методы, которые будут выполнять группы операций INSERT, UPDATE, DELETE при этом вам приходится «плодить» горы исходного текста.  
2.    Попытаться написать универсальный механизм, а это означает попытку смоделировать мини ORM систему собственными силами.

В случае транзакций на чтение вопрос обстоит еще хуже, когда требуется извлекать много связанных объектов. В зависимости от ситуации вы должны писать или один запрос соединяя множество таблиц, а затем разбирать результирующий набор на части, либо писать несколько запросов и совместное выполнение их обеспечивать программным образом. И здесъ имеется та же самая альтернатива, либо писать много специализированного кода, либо писать нечто универсальное (ORM систему?).

Hibernate обкатана тысячами разработчиков за много лет. Пойдите и реализуйте своми руками автоматическое «лениевое» извлечение связанных объектов или кэш второго уровня.  То есть в случае мало-мальски сложной системы  у вас имеется альтернатива - либо писать и отлаживать много специализированного кода, либо писать свою ORM систему. Если она окажется лучше Hibernate, честно обещаю использовать ее в собственных разработках. Извините за многословность – не хочется выглядеть дураком, которым меня пытаются представить.

И последнее моё добавление, чтобы избавиться от недомолвок. Объектно реляционное отображение требуется не от хорошей жизни, а от нестыковки реляционного хранения с ООП (это все знают). Однако некоторые, решая эту проблему, вновь и вновь пишут специализированный код, а другие берут универсальное решение (готовую ORM систему). За универсализм всегда приходится платить некоторым снижением эффективности работы.  Однако, как сегодня никому в голову не приходит писать системы на Ассемблере, так сегодня использование ORM системы для взаимодействия с базой данных становится общим местом.

И Sun  и  Oracle окончательно сняли свои курсы по JDBC, которые раньше у них были. Сначала я посокрушался по этому поводу, а потом понял это симптом. 

Имеются в виду, очевидно, транзакции бизнес уровня, а не каждого отдельного SQL-запроса.

Shaggie, так точно. Однако, согласитесь - в конечном итоге, транзакции бизнес уровня плавно перетекают в транзакции СУБД. 

Например, при использовании EJB вы можете в цепочке вызова методов, для каждого из методов описать открытие и, соответственно закрытие транзакции, однако в конечном итоге вся цепочка приводит к завершению или откату транзакции в контексте постоянства, а значит и в СУБД. С учётом возможности использования для каждого метода декларативной авторизации мы получаем довольно мощный инструмент. Хотя надо честно сказать для относительно простых приложений достаточно ORM. Однако при этом все остальное надо писать вручную.