rgb-dart
Если коротко, то полностью согласен с Один1 . Стоит лишь дополнить, что любую полезную идею можно применить "не там и не так".

Если чуть подробнее, то я не уверен, что Вы понимаете под Data Access Layer, поскольку этот термин употребляется в нескольких существенно разных с моей точки зрения смыслах.

Первый смысл - "интеллектуальный адаптер данных". Суть его в том, что приложение работает с данными, удобно организованными с точки зрения их смысла и использования. К примеру, справочники доступны как ассоциативные массивы, parent-child иерархии обсчитаны и собраны удобно для их представления в древовидном интерфейсе, внешние ключи замены ссылками на реферируемые объекты итп. Это безусловно удобно - если требуется в приложении. Для того, чтобы это громоздкое и сильное решение было оправданным, приложение должно осуществлять большую и сложную обработку данных; в целом это подход скорее для серверов приложений и тяжелых клиентов, но не для систем класса "ввод данных плюс отчеты".

Второй смысл - "абстрагирующий слой без претензий". Как правило идет в сочетании с идеями независимости от БД, возможности подключения нестандартных источников данных, каких-нибудь текстовых файлов, итп. Также разумная мысль, полезная при соблюдении одного условия - недовольство существующими классами. К примеру, если считать, что ADO покрывает все мыслимые требования доступа к данным - незачем реализовывать еще один класс, являющийся тупой прокладкой, proxy для вызова соответствующих методов ADO. Если нет - такая прокладка удобна и уместна, чтобы например для Oracle использовать ODP.

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


Речь идет об использовании объектов доступа к данным в клиент-серверном приложении (учетной системе). Система на WinForms (C#) и MSSQL Server.

1. В чем, по вашему, преимущества использования слоя доступа к данным?
2. Есть ли у вас ссылки на высказывания авторитетных специалистов по этому вопросу (книги, статьи)?
3. Считаете ли вы целесообразным рефакторинг кода наполовину написанной системы, в которой слой доступа к данным не был даже задуман? То есть, считаете ли вы, что потратив время на реализацию слоя доступа к данным для уже "вроде как готовых и работающих" компонент (модулей) можно получить выигрыш по времени за счет сокращения времени на
а) поиск и исправление дефектов в этих модулях
б) реализацию новых меняющихся требований к этим модулям

Интересует мнение опытных специалистов (каковыми, я уверен, являются большинство форумчан). =)[/quot]

rgb-dartНе согласен. Представьте, что у вас обращения к базе идут прямо с форм.......
Я упомянул, что понятие DAL имеет существенно разные трактовки, разные смыслы - и естественно, я назвал только направления, в то время как в реальных проектах часто оказываются реализованными те или иные компромиссы между этими подходами.

Вы описываете то, что довольно близко к названному мной первому смыслу. Нисколько не возражаю и сам же упомянул; нормальный для своей ситуации подход. Но! Вы возражаете на то, что я сказал о другом подходе, номер два в моей трактовке. Это другой подход со своими плюсами и минусами. Подумайте над смыслом Вашей фразы: "Я полагаю, что названное softwarer-ом условие применимости метода2 неверно, потому что я предпочитаю метод1". Странновато звучит, правда?

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

Могу сказать так. У меня был проект, в котором заказчик настоял на использовании объектного слоя и по итогам этого проекта я так и не увидел, чтобы этот проект получил с него что-то кроме увеличения времени разработки. У меня сейчас идет проект, который без объектного слоя просто загнулся бы. Все зависит от конкретного случая.

rgb-dartВ случае если придется переделывать GUI, вам будет легче это сделать, если логика получения данных вынесена в отдельные классы а не находится на форме.
К сожалению, не факт. Я до сих пор вспоминаю одну систему, в исходниках которой мне довелось порыться, написанную в парадигме "все на сервере". В результате на сервере оказались хранимки, суть которых была теснейше привязана к интерфейсу (практически подготовка данных в удобном для интерфейса виде), и в результате для модификации интерфейса (что собственно меня попросили сделать) пришлось лезть еще и дорабатывать хранимки.

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