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

 
 
 
Сообщения:284
AndroidJunior:
Вот не понимаю почему нельзя запилить какой-нибудь мега редактор по типу 1с который бы генерил 99% дао?


платформа 1С - это конструктор, который генерирует не только работу с БД, но и полноценный view.
Да и ДАО при желании там тоже можно запилить в виде общего модуля, правда он там нафиг не сдался, тк работа с БД только через свою ОРМ.

Quote:
В Oracle SOA Suite/Oracle Service Bus есть DBAdapter

Это клево, но хочется что-то более земного :)
 
 
Сообщения:2398
Староверъ:
Плюс - вариант перехода с ORM на JDBC более вероятен (а он намного проще), потому как недостатки ORM на первых порах не являются критичными в отличие от его плюсов (скорости разработки). А потооом, когда будем больше работать над NFR, тогда уже и может понадобиться переход на JDBC - при этом JDBC & ORM будут очень долго сосуществовать.

Ну вот именно так обычно и проиходит: берут ORM, быстро пишут весь персистенс (чистый JDBC с нуля требует раз в 5 больше времени по трудозатратам). Потом начинают оптимизировать. Мы начали это делать где-то через год после выхода в продакшен. В некоторых случаях начинают упираться в ограничения традиционных средств JDBC и приходится переключаться на специализированные функции JDBC-драйвера (к примеру, Oracle Performance Extensions). ORM в DAO не всегда полностью уходит, но его куски могут переписываться под специфические нужды.
Недостаток отсутствия DAO - в случае если надо добавить оптимизации, а обращения к базе осуществляются из кучи мест, сделать такую правку в одном месте не получится - придется копать код и искать, где все эти saveOrUpdate вызываются и копипейстить один и тот же код.

Еще один плюс DAO - удобно разбивать на задачи девелоперам в команде: кто-то занимается слоем DAO (в случае JPA, там больше работы по тестированию, тюнингу кеша и каскадирования, чем, собственно, написания самого кода работы с базой); а кто-то другой - бизнес-логикой. При этом единственная точка контакта между ними - интерфейс DAO.

Изменен:26 сен 2014 15:05
 
 
Сообщения:390
Не вижу предмета для спора для синьор девелоперов, кому ДАО избыточно, те его не используют, кому ДАО нужно те используют, зачем так много писать-то, когда в вопросе легко разобраться сопоставив функциональные и не функциональные требования к приложению и имеющиеся в наличии ресурсы для их реализации, тем более что думающие человеки даже если изначально промахнилиь с архитектрой то избавится или введут ДАО по мере возникновения проблем.
Изменен:27 сен 2014 10:40
 
 
Сообщения:2436
В моём понимании ДАО это всего лишь подмножество шаблона gateway не больше не меньше. Отказываться от него и размазывать равномерным слоем работу с внешней системой(хранилищем) по всему коду приложения, в общем случае я не вижу никаго смысла, как для примера не вижу смысла размазывать повсюду скажем код работы с почтовым сервером или код работы с брокером сообщений, но тем не менее я не исключаю, что отказаться от ДАО в каком-то конкретном случае является оправданным решением, как и написать проект на groovy или ruby, я не в коем случае не спорю что инструмент нужно выбирать под задачу, а не подгонять задачу под имеющийся инструмент, просьба читая далее написанный текст, не считать меня закостенеллым поборником шаблонов.

Что даёт нам ДАО в простых проектах:
  • Легкое тестирование(естественно только юнит и мутационное) слоев лежащих выше ДАО, более высокая скорость сборки проекта, так как тесты для ДАО можно не прогонять, если оно не менялось, за то время которое мы тратим на тестирования одного SQL запроса, можно было бы протестировать тысячу методов бизнесслогики если она отвязяна от хранилища.
  • Легкое тестирования запросов к хранилищу, так как они не перемешанны с бизнесслогикой, то их их можно тестировать отдельно от неё. Согласитесь одно дело прогнать десять тысяч SQL запросов за сборку, время конечно существенно но терпимое, другое дело прогнать десять милионнов SQL запросов из-за того, что мы не можем выполнить тестирование бизнесс-логики отдельно от системы хранения и старание покрыть как можно больше веток в бизнесс-логике оборачивается тем, что во время тестов придется выполнять больше и больше заросов к хранилищу, больше и больше, всё больше и больше с каждым новым требованием, и это упаси вас боже от того что ваш проект выстрелит и начнет зарабатывать деньги, тогда хотелки польются сплошным потоком и за прогоном тестов можно будет спокойно сходить сгонять партейку другую в соседний боулинг клуб.
  • Соблюдение single responsibility - код отвечающий за предметную область находится в сервисах(или в доменных объектах если вы упоротыйярый DDD-шник), а код отвечающий за работу с хранилищем в другом. Естественно я понимаю что SOLID, что дышло как повернул так и вышло, и естественно трактовка единственный случай когда я должен менять слой бизнесс логики, это когда изменяются требования к бизнесс процессам может не проканать из-за того что скажем придется поменять бизнесс логику без изменения функциональных требований к системе, просто потому что в ДАО с целью оптимизации произошли такие изменения, что оно больше не может соблюдать прежний интерфейс, и как следсвие нам нужно менять вышестоящий слой. Но всё таки я считаю, что выделение ДАО в отдельную сущность в подавляющем большинстве случаев способствует соблюдению single responsibility, нежели его нарушению.

На этом плюсы использования ДАО в простых проектах заканчиваются и начинаются одни только минусы, очень хорошо описанные в статье, копипастить минусы я не буду, желающие могут пройти по ссылке и прочитать. Если у Вас простой проект и минусы перевесли плюсы, то никто Вас не осудит если Вы откажетесь в своем проекте от ДАО с целью быстрее его сдать(с другой стороны а зачем вам java а не ruby/python но это уже совсем другой вопрос).

Что же касается нетривиальных проектов либо со сложной бизнесс логикой, либо со сложными нефункциональными требованиями то, то что написанно ниже можно было бы и не писать, и так ежу понятно что если разработчики изначально отказались от ДАО, то понабивавши шишек они этот шаблон обратно введут(даже если для этого придется убить архитектора), но всё таки напишу пункты которые возникли в моей личной практике:
  • Если нужно было распаралеллить работу и выполнить её как можно быстрее, то это делалось согласованием общего интерфейса ДАО, а дальше уже две команды работали паралельно переодически корректируя интерфейс. Плюс возможна ситуация когда по каким, то причинам реализация кода доступа к хранилищу еще не готова, то можно заменить ее на работу с коллекцией в памяти или просто замокать. Ежели програмисты пишущие доступ к хранилищу и программиств пишущие безнесс слой будут править одни и те же классы одновременно, то даже страшно представить себе сколько временни уйдет, только на решение конфликтов слияния, не говоря о качестве кода, конвенциях, покрытия тестами и прочих нестыковках которые могут возникнуть при столкновении двух культур.
  • Если нужно обеспечить высокое качество выплоненных работ, то опять же лучше чтобы разработчики слоя доступа к данным, как правило не знающие лучших практик разработки для серверов приложений и лучших практик программирования вообще, не толкались на одном пяточке с java разработчиками которые хороши как прикладные программисты, но не знают глубоко детали конкретного хранилища данных в следствии чего хорошего кода доступа к данным никогда не напишут.
  • Был случай когда хранилище данных было очень сложно и требовало, чтобы разработчики посвятили его изучению достаточное количество времени(voltdb). В таких ситуациях даже если никто не ставил перед собой цель написать систему привлекая только профессионалов своего дела узких специалистов, всё равно придётся выделять отдельных разработчиков и ставить перед ними цель детально ознакомится именно с функционалом хранилища и оградить их от остальных задач на проекте, позволив писать только реализацию ДАО.


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

За исключением запрещенных ударов диалектики, статья очень понравилась, она лишний раз заставляет зуматься зачем ты делаешь то что делаешь, огромное спасибо!
Изменен:27 сен 2014 21:33
 
 
Сообщения:2398
Vermut, отлично написал. Полностью поддерживаю.

 
 
Сообщения:586
По поводу смены СУБД, дело как раз в том, что такие и сеньоры, и архитекторы есть и их много слышно, иначе я бы и статью писать не стал. Это, собственно, основное в моем мнении: ДАО позиционируется как нечто, позволяющее волшебным образом сменить слой хранения, не только СУБД. При этом под сменой СУБД понимается смена типа СУБД с реляционной на noSQL и наоборот. Проекты, в которых меняли просто Oracle на DB2, я видел - у одного заказчика одна реляционка, у другого - другая, тут нам поможет Хибернейт, проблемы нет. Причем описанные вопросы поддержки СУБД не существенны: ПО бывает не только внутреннее, но и коробочное и один заказчик вполне может иметь всю необходимую инфраструктуру под одну реляционную СУБД, а другой - под другую. Проектов же по реальной смене типа хранилища не видел, но и на sql.ru, на других форумах, в сообществах по .net и вообще в сети эта мысль подспудно витает: сменим слой ДАО и у нас волшебным образом все заработает. Этакий карго-культ: все так делают, пишут ДАО, и мы будем, вдруг, когда наступит коммунизм, нам слой хранения поменять надо будет. Впрочем, я рад, что здесь на форуме в итоге согласились, что функционально данный слой ничего не дает, только облегчает тестирование и чтение кода.
Изменен:28 сен 2014 06:56
 
 
Сообщения:43
samolisov:
вдруг когда наступит коммунизм, нам слой хранения поменять надо будет.

Кастую пост на хабре... "Как демократичные санкции заставили программистов нашего банка постичь великое ДАО" ;)
 
 
Сообщения:390
samolisov:
По поводу смены СУБД, дело как раз в том, что такие и сеньоры, и архитекторы есть и их много слышно, иначе я бы и статью писать не стал.

Я лично с такими людьми по работе не пересакался, и надеюсь что и дальше всё будет складываться так, что с людьми имеющими такое мнение на одной работе не пересекусь. Статья хорошая, и вывод правильный:
samolisov:
Радикальная смена подсистемы хранения только посредством использования паттерна DAO - миф.


Но название статьи, очень сильно троллящее. Вместо того, чтобы назвать её о спорном паттерне ДАО, я бы назвал её как-то в стиле почему паттерн ДАО не обеспечивает прозрачной смены СУБД, тогда и коментарии к статье были бы более содержательные, как за так и против, я бы сам лично привел пару кейсов когда кукишь Вам а не прозрачность, да и больше половины постов в этой теме можно было бы не писать.

samolisov:

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

Что значит только, Вы писали это она полном серьезе или шутили?) Тестируемость и читаемость, для многих здесь основные драйверы разработки, в отличии от мифической возможности сменить шило на мыло когда либо в будущем, тестируемость и single responsibility это реальные выгоды которые извлекаешь от ДАО здесь и сейчас, собственно как и грабли от их отсутсвия проявляются в большом проекте незамедлительно. Но могут быть и есть всякие сайты визитки(условно), цикл разработки которых короток и покрытие юнит тестами неважно, так как функциональности кот наплакал и ее можно покрыть приемочными блэк-бокс тестами, здесь естесвенно любой агитирующий за ДАО будет не прав.
Изменен:29 сен 2014 21:12
 
 
Сообщения:586
vimba:
тестируемость и single responsibility это реальные выгоды которые извлекаешь от ДАО здесь и сейчас

Это тоже во многом карго-культ, потому что существует множество проектов, в которых ДАО есть, а тестов нет. Очень крупных проектов, разрабатываемых уже более 10-ти лет. И вот люди вынуждены добавлять метод сначала в интерфейс сервиса, потом в его реализацию, которая в 90% случаев состоит лишь из вызова метода ДАО, потом в интерфейс ДАО, потом в его реализацию... И все эти пляски только потому что дядя из Spring Framework сказал, что IoC это мего круто и показал это на примере "вот смотрите у нас есть ДАО, мы его скрыли за интерфейсом и инъектировали в сервис, а завтра так раз и заменим другим ДАО и это все сделать нам позволят две вещи: ДАО и наш любимый Spring Framework". Да-да, часто примеры про сменяемость слоя хранения идут со стороны евангелистов IoC-контейнеров ибо это их хлеб, а пример очень такой наглядный, на многих действует завораживающе, что и данная тема показывает. Ну сейчас вероятно еще евангелисты TDD подключились к процессу.

Мне интересно как могут выглядеть модульные тесты слоя ДАО. Модульный тест он же вроде как по-определению не должен соединяться с БД и что-то там делать. И что в результате тестируется? Что метод ДАО генерирует определенный запрос? А толку? Кто сказал, что этот запрос правильный и эффективный? Или коллеги делают все по максимуму: берут реальную СУБД, под которой предполагается эксплуатация, создают там тестовые данные, затем выполняют метод ДАО через интеграционные тесты и смотрят, что же он нам вернул? Вы реально это делаете или у вас где-то завалялся мок Oracle?

Коллеги выше писали, что интеграционные тесты (я так понял, раз там речь шла о запросах, то ввиду имеются именно интеграционные тесты) для ДАО выполняются быстрее, нежели для БЛ и можно сэкономить время. Это наводит на мысль, что коллеги отказались от интеграционных тестов для БЛ. На мой взгляд довольно странное решение, т.к. одно дело иметь правильно генерируемые и работающие запросы и совсем другое - правильно работающее да еще и во многопоточной среде приложение с учетом уровней изоляции транзакций, правильной демаркации их границ, логирования, безопасности и т.д. Получается, что нужно иметь два набора интеграционных тестов: один для ДАО, другой - для всего приложения в целом. Понятно, что время работы двух наборов тестов будет всегда больше нежели одного. На этом фоне смысл иметь отдельный набор интеграционных тестов только для ДАО несколько меркнет.

Единственный момент, с которым можно безоговорочно согласиться и который, кстати, в обсуждении на форуме не упомянули, что наличие ДАО помогает тестировать не запросы к хранилищу, а реакцию бизнес-логики (БЛ) на результаты выполнения этих запросов. Мы можем сделать МОК ДАО и проверять поведение нашей БЛ на различных наборах данных. Но не велика ли цена удобства, особенно если учесть, что модульные тесты для часто меняющихся частей программы (где-то выше прозвучало слово "требования") вещь ненужная и скорее вредная, а в действительно крупных системах бизнес-логика вообще размазывается по нескольким приложениям (тут и BPM, и Business Rules/Decision Maker, и SOA) и мокать придется много всего.

Обновил ответ.
Изменен:30 сен 2014 06:53
 
 
Сообщения:390
samolisov:
Это тоже во многом карго-культ, потому что существует множество проектов, в которых ДАО есть, а тестов нет. Очень крупных проектов, разрабатываемых уже более 10-ти лет. И вот люди вынуждены добавлять метод сначала в интерфейс сервиса, потом в его реализацию, которая в 90% случаев состоит лишь из вызова метода ДАО, потом в интерфейс ДАО, потом в его реализацию...

Проблемы индейцев, как говорится шерифа не это самое... У некоторых багтрекера нету, так что давайте будем говорить, что jira устарела?

samolisov:
И вот люди вынуждены добавлять метод сначала в интерфейс сервиса, потом в его реализацию, которая в 90% случаев состоит лишь из вызова метода ДАО, потом в интерфейс ДАО, потом в его реализацию...

Это не правда, как раз таки в большинстве случаях в сервисах всегда есть логика, которая всегда разрастается по мере увиличения бизнесс плюшек, если это не так то сильно похеоже на то, что люди прнимавшие решение о выборе способа реализации сильно ошиблись с языко программирования. попробйте порассуждать над процитированным предложением философски? У вас нет бизнесс-логики есть только код доступа к данным, но при этом Вы предлагаете оставить шаблон применения которому нет, но при этом удалять шаблон который железобетонно применим.

samolisov:

Мне интересно как могут выглядеть модульные тесты слоя ДАО. Модульный тест он же вроде как по-определению не должен соединяться с БД и что-то там делать. И что в результате тестируется? Что метод ДАО генерирует определенный запрос? А толку? Кто сказал, что этот запрос правильный и эффективный? Или коллеги делают все по максимуму: берут реальную СУБД, под которой предполагается эксплуатация, создают там тестовые данные, затем выполняют метод ДАО через интеграционные тесты и смотрят, что же он нам вернул? Вы реально это делаете или у вас где-то завалялся мок Oracle?

А кто сказал что тесты ДАО должны быть модульными? ДАО выносится в отдельный компилируемый модуль, тесты гоняются на СУБД приближенной к реальности, тестовые наборы данных подготавливаются с помощью dbunit, код доступа зачастую пишут выделенные программисты.
 
 
Сообщения:586
vimba:
У вас нет бизнесс-логики есть только код доступа к данным

По поводу того, что раз логики нет, то и сервисы не нужны, а ДАО - нужен. Помимо явной реализации какой-то логики сервисы, как правило неявно, отвечают еще за очень много вещей, например за разграничение транзакций. Вот транзакции всем нужны, а ДАО, особенно в том виде, в котором его зачастую предлагают, как некий набор классов, инкапсулирующих в себе запросы к БД, - спорно, отсюда и обсуждаемачя заметка.

vimba:
код доступа зачастую пишут выделенные программисты.

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

vimba:
тесты гоняются на СУБД приближенной к реальности,

А потом еще гоняются интеграционные тесты всего приложения? Тесты ради тестов?

vimba:
сильно ошиблись с языко программирования

Про навязчивую идею, что DAO в частности и Java в целом - это такой признак "элитности" и применять ее надо только для приложений, содержащих сложную бизнес-логику. Почему-то ни одно из крупных, прямо таки насыщенных логикой приложений, например систем планирования и управления ресурсами предприятия (ERP) не написаны на Java, ни SAP, ни Oracle Business Suite. Java там конечно есть, у SAP даже целый свой сервер приложений, но скорее как дань моде и возможность нанять дешевых программистов. Но это так, офтоп.
 
 
Сообщения:284
samolisov:
ни SAP, ни Oracle Business Suite

оффтоп, конечно, но данные продукты писались еще до появляения java
 
 
Сообщения:284
По итогам беседы мнения разделились:

1. Версия Павла - DAO не нужен, потому что лениво писать/поддерживать "ненужный" интерфейс и тестирование ДАО слоя не обязательно

2. Версия сообщества - ДАО улучшает восприятие кода, его читаемость + позвояет ввести дополнительные тесты, а также обеспечивает какое-никакое абстрагирование от СУБД
 
 
Сообщения:1517
всю тему не читал, но мне нравится принцип CQS (command query separation) и CQRS (command query responsibility segregation в частности). В доменной логике имеется репозиторий, в котором есть по сути 2 метода: getById, save. Все изменения в состоянии публикуются в виде событий. Специально обученые обработчики событий из них строят денормализованое представление данных. А DAO это такая свалка по типу всяких *Util классов, содержащая методы которые не смогли отнести к какой то более подходящей абстракции.
 
 
Сообщения:390
samolisov:
vimba:
У вас нет бизнесс-логики есть только код доступа к данным

По поводу того, что раз логики нет, то и сервисы не нужны, а ДАО - нужен. Помимо явной реализации какой-то логики сервисы, как правило неявно, отвечают еще за очень много вещей, например за разграничение транзакций. Вот транзакции всем нужны, а ДАО, особенно в том виде, в котором его зачастую предлагают, как некий набор классов, инкапсулирующих в себе запросы к БД, - спорно, отсюда и обсуждаемачя заметка.

Все те же аннотации и интерсепторы можно навесить и на ДАО, результат будет абсолютно тот же самый.

samolisov:

vimba:
код доступа зачастую пишут выделенные программисты.

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

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

samolisov:

vimba:
тесты гоняются на СУБД приближенной к реальности,

А потом еще гоняются интеграционные тесты всего приложения? Тесты ради тестов?

Тесты ради того, чтобы ты смог проверить качество своей работы сразу же. Если я отдаю функционал поверх которого будет еще что-то написано, то я должен удостовериться, что то что я сделал работает. Полный комплект функциональных тестов может и сутки прогоняться, плюс от реализации работы с БД, до того как этим кто-то воспользуется может пройти время, и в течении этого времени я не буду понимать рабочий ли код я написал. Запустив тест на только что написанный метод в ДАО, я могу проверить его незамедлительно. Несмотря на то, что сами по себе тесты ДАО через базу не очень быстрые, но проводить исчерпывающее тестирование через вышестоящии слои это еще медленнее.

samolisov:

vimba:
сильно ошиблись с языко программирования

Про навязчивую идею, что DAO в частности и Java в целом - это такой признак "элитности" и применять ее надо только для приложений, содержащих сложную бизнес-логику. Почему-то ни одно из крупных, прямо таки насыщенных логикой приложений, например систем планирования и управления ресурсами предприятия (ERP) не написаны на Java, ни SAP, ни Oracle Business Suite. Java там конечно есть, у SAP даже целый свой сервер приложений, но скорее как дань моде и возможность нанять дешевых программистов. Но это так, офтоп.


Таких приложений огромное количество достаточно привести хотя-бы альфреско, краткий обзор возможностей которой занимает лишь 500 страниц, а если посмотреть статистику зарплат, то java прогаммисты вообще-то не самые дешевые. Вы просто не можете смириться с тем что паттерн ДАО на самом деле нужен, и спорите уже на автомате. Вам привели конкретные факты на которые у Вас нет другого ответа, кроме как в стиле а для меня это не важно. Вам вообще полезно было бы понять, что у разных разработчиков разные приоритеты, то что не важно Вам, важно для других. Заметьте Вам тут никто не говорит, что именно Вам обязательно нужно писать юнит тесты на бизнесслогику, не хотите не пишите ради бога, хотите смешивать в кашу из SQL, HQL из бизнесс требований пожалуста, просто Вам нужно принять как должное, что вегда будут программисты которые не пойдут на такой проект после собеседования, или уйдут на первой неделе испытательного срока. Поскольку никакого конструктива с Вашей стороны нет, а менять повестку обсуждения с ультимативной ДАО не нужен, на в каких случаях ДАО ненужен а в каких нужен, или почему ДАО не дает стопроцентной гарантии безболезненной смены СУБД, то продолжать обсуждение я для себя смысла не вижу, так как не получаю из него, хоть что-то полезное для себя.
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет