locky
поправьте, если ошибусь.
1. если вся логика на серваке, то клиент фактически - набор сторед проц
и гридов. замена сторед процев на другие - это половина клиента (не
забывая возможные настройки и т.п.) работа в принципе рутинная, но
чреватая ошибками. проверено переходом с BDE на ADO.
2. ну, тут на вкус... ФБ вроде как не умеет управлять транзакциями
изнутри ХП, значит управление идет с клиента. Оракл вроде как умеет, но
зуб даю - с клиента несколько проц вызываются - последовательно в рамках
одно транзакции, значит и с ораклом ситуация будет та же.. Некрасиво, ИМХО.
3. если таки делфин - никаких "классов доступа" - набор формочек. так шта...

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

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

locky
Это Вы мне рассказали, как должно быть по хорошему? абсссолютно с Вами
согласен. Боюсь только, что в реальности всё несколько хуже :-)

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

locky
снова сакраментальный вопрос: зачем?
Есть система, работает, выполняет свою работу, все ею довольны.
на кой черт её перепахивать?
а я потому и написал
StalkerS
то при модернизации приложения его следует распахать

Понятно, что если его не модернизируют, то и вообще не надо в код лезть. А то, что перепахивать долго придется... Так если не перепахивать, его рано или поздно вообще придется выкинуть на свалку. Это-же как с зубами - если не обращать внимание на кариес - рано или поздно зуб останется только выдернуть, а при своевременных осмотрах - будет чем жевать в старости

softwarerНе слушайте всякую чушь. Толстый клиент без специальных классов запросто может быть правильным.

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

Anton Demidovdata level отделяют от business logiс level, если хотят первый легко заменить в будующем для поддержки другой БД без большого "перелопачивания" всего кода.
;) прочитайте на первой странице, там именно об этом речь и шла.

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

Чем мощнее методика проектирования, тем более осторожно с ней надо обращаться, тогда и результат глядишь лучше получиться. Ваша мысль о том, что надо думать что делаешь, прямо скажем не является открытием Америки :)

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