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

Дмитрий Сорокин tygraВы что-то путаете, уважаемый :)
В архитектуре приложений куда без ООП? Именно оно там и рулит. А вот в архитектуре бизнес-логики - извините, при чем тут ООП? Какой ООП может быть, если у вас таблицы в БД?

Так что вы отделите мух от котлет - и все встанет на свои места.

Клиентская часть - это только интерфейс системы, тут ООП.
Серверная часть - это БЛ системы. Тут ХП.
.

Погодите-ка. А что есть приложение без бизнес-логики? Интерфейс? И ООП нужна для рисования клиентской части? Однако. По моему при написания интерфейса (не создания библиотеки визуализационных элементов, а именно реализации конкретного интерфесса) ООП применима лишь в ограниченном смысле. Конечно можно наследовать уже созданные формы, но покажите мне того, кто это делает:)
Оопс. Оказывается ООП не для наследования форм, создания визуальных и невизуальных повторноиспользуемых компонент создано и все исключительно его по назначению используют - с множествами данных работают Ну круто. А Вы что, правда интерфейсы каждый раз с нуля рисуете или у Вас что то, что имеет ограниченные возможности в этом плане ( Delphi например не сильна ;) ). Зайдите-ка на форум PowerBuilder. Там с иерархии интерфейса построение клиентского приложения и начинается, а вот работу с данными как раз на себя берет DataWindow, который ничего близкого к ООП не имеет, а является аналогом локального хранилища, визуализации и обработки данных (даже со своим внутренним языком), которое получает данные с внешних источников.

Дмитрий Сорокин tygra
Так что нужно хоть попробовать представить, что хочется, а потом представить - а надо ли это?
Да я и не пойму - кто вам мешает использовать инкапсуляцию и т.д. в клиентском приложении?
Я не пойму вашей проблемы :)


Поясню. Я хочу при написании бизнес-логики оперировать не таблицами и хранимыми процедурами, а объектами, свойствами и методами. Помимо этого я хочу инкапсулировать бизнес-логику и данные. Плюс, иметь возможность наследовать уже созданную бизнес-логику. И т.д. и т.п. Именно это дает (при всех их недостатках) использование среднего слоя и серверов приложений. Так работают J2EEшные сервера, так позволял работать MTS, так вы работаете с ABAPом в SAPе, к этому призывает микрософт, говоря о веб-сервисах.
Можно глупый вопрос - а зачем Вы хотите оперировать обьектами, свойствами и методами ? И кстати и веб-сервисы уже не только удел 3-х звенок - например в РСУБД ASA9 собственный встроенный веб-сервер и полноценная поддержка веб-сервисов, которые очень удачно и кратко пишутся на языке хранимых процедур, работа с внешними веб-сервисами и полная поддержка XML. Ну и ... зачем тогда ООП ?

Ну давайте уважаемые адепты 3-х звенок спустимся наконец на землю и на конкретных примерах от вас услышим, что же это за бизнес-логика такая у вас сложная, что она выльется в тысячи хранимых процедур с большим кол-вом кода, да еще который из за изменения ТЗ весь почему то лопатить придется ? У меня вот никак не получается придумать - и расчет зп на ХП нормальный и расчет коммуналки не хуже, и расчет по графам потребления энергии для РАО на ХП и даже свой компилятор хранимых процедур на базе HTML макетов, которые дальше для веб-сервисов генерили по макетам HTML (можно сказать в чем то аналог PHP/ASP, но с поддержкой еще макросов, где в качестве встроенного языка был сам язык хранимых процедур) ... причем писал я этот компилятор ... как раз на ХП (их меньше 10 штучек получилось и кода тоже много не наблюдалось). В чем же тогда дело ? А как в бедных функиональных языках без ООП живут, ну просто ума не приложу