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

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

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

softwarerL1GС точки зрения автоматизированного тестирования, например, второй подход лучше, хотя и он недостаточен: бизнес-логика должна быть отделена как от интерфейса, так и от логики хранения данных.
В этих словах Вы ухитрились допустить сразу две ошибки. Во-первых, как уже обсудили выше, отделение бизнес-логики либо чего-то другого никак не зависит от сравниваемых подходов и равно может присутствовать либо отсутствовать в любом из них. Во-вторых же, у Вас ложные представления об автоматизированном тестировании. Судя по тому, что Вы сказали, Вы имели в виду юнит-тестирование. Однако, юнит-тестирование приложений работы с БД нерационально, в то время как автоматизированное тестирование куда шире, применимо для подобных приложений и равно способно тестировать как "отделённые", так и "совмещённые" приложения.

"Во-вторых", я имел в виду вовсе не юнит-тестирование, а тестирование более крупных функциональных блоков (хотя не уверен, можно ли его считать интеграционным). Конкретнее - такое, при котором для скорости реальную СУБД приходится подменять тестовым хранилищем данных в ОЗУ.

Насчет "во-первых" - действительно, автор говорил только про использование визуального дизайнера для БД-компонент. То, что при этом использовались еще и db-aware controls с заданной в их свойствах привязкой к БД-компонентам - это уже моё предположение. Верное или нет - пока неизвестно.

DmSerТакже стараюсь по возможности разрабатывать классы, например TUser, TContragent, и т.п. и в их методах реализовать всю работу с бд. В этом случае сложность программы уменьшается на порядки и никакой ORM не нужно.Уточняя терминологию: считывание объектов из БД и их сохранение обратно и есть O bject- R elational M apping.
То, что в данном случае ненужно - это сторонний ORM- Framework .