Стоит ли отказываться от слоя DAO?

 
 
 
Сообщения:1517
samolisov:
Если нужен менеджер блокировок, то обращаться к нему нужно из слоя бизнес-логики, аналогично тому, как вы обращаетесь к менеджеру транзакций. Если хотите, то можно это даже в аспект оформить.

я все никак не могу понять.. как транзакции и блокировки связаны с "бизнес-логикой"?
 
 
Сообщения:586
Именно бизнес-требования определяют атомарность, консистентность, изолированность, долговечность. Банальный пример: мы удаляем пользователя и переносим в архив все его документы. Это - бизнес-логика? Да. А если при переносе документа в архив произошел сбой, мы должны отменить всю операцию или наоборот, то что уже удалось сделать - оставить? Или если при удалении произошел сбой - надо ли извлекать из архива то, что мы уже туда положили? А если надо, то отдельной проводкой или нет? И вот если надо, да еще и отдельной проводкой, то получается, что действия с пользователем и архивом должны быть обернуты в транзакцию, а формирование проводок нужно выполнить в отдельной транзакции, а может и вообще без нее. Все это части бизнес-логики.
 
 
Сообщения:1517
это все не транзакции БД. и какой тут может быть "менеджер транзакций"? я тут вижу некоторое действие и при возникновении проблем компенсирующее действие.
 
 
Сообщения:586
Еще момент, когда слой ДАО может быть очень полезен, но он несколько экзотический и касается системной интеграции. Когда логика одна и та же, но выполняется над разными данными. Ну например: перелей из пустого в порожнее и залогируй. Но таких информационных потоков штук 20. В этом случае мы получаем и прелести полиморфности ДАО, т.к. он теперь привязан не к СУБД, а к информационному потоку, которых в приложении много, и если хотите переносимость, только не между источниками данных, а между инфопотоками. Тогда в одной реализации ДАО мы описываем извлечение например сведений о справочнике КЛАДР, в другой - о клиетах, в третьей - об услугах, ну и аналогично делаем сохранение.

Сегодня работаю адвокатом дьявола прям.
 
 
Сообщения:586
Почему не транзакции БД? Именно о них и шла речь - получили сбой, откатили. Транзакции на компенсациях применимы, когда у нас длительные действия да еще и с участием людей, в приведенных примерах их городить не нужно.
 
 
Сообщения:1517
тогда тем более им не место в бизнес-логике. она ничего не должна знать о какой то там БД и ее сбоях. это уже будет определяться где то в инфраструктуре.
 
 
Сообщения:586
В идеальном мире это так. В реальном мы имеем обычно реляционную СУБД, в которой есть два АПИ, запросы к данным и транзакции. Про то, куда помещать запросы к данным мы здесь и спорим. Большинство считает, что для этого нужен отдельный слой - ДАО, некоторые аргументируют. С аргументами можно соглашаться, можно - нет, преломляя через свой опыт. Управление транзакциями обычно реализуется через обертки, которые могут абстрагироваться от конкретной реализации, например JTA. Там вообще может быть не СУБД, а очередь. Это если еще не брать в расчет взрослые менеджеры транзакций, такие как CICS и IMS TM. Здесь все более стандартизировано: бизнес-логика решает какие операции должны быть выполнены в транзакции, стартует ее, выполняет операции, коммитит. Она работает не с БД, а с неким транзакционным хранилищем. Конечно и тут есть упрощения. Если вы решили, что у вас каждая операция БЛ будет в транзакции, то вы можете создать фасад, в котором их стартовать и коммитить, а логика останется чистой. Но так сделать можно не всегда, иногда гранулярность транзакций не совпадает с гранулярностью операций, вызываемых из слоя представления/сервисов.
 
 
Сообщения:9895
Эх, уже ругаться начали. Я думаю что все успели выразить свои мысли по поводу темы и теперь это переросло в эмоции, за сим тему закрываю чтоб не продолжали месить воду в ступе.
Спасибо все кто принял участие в обсуждении. Отдельное спасибо samolisov'у за статью и за пищу для размышлений!

PS: багу по цитированию проверим и пофиксим если воспроизведется :)
Изменен:01 окт 2014 04:51
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет