Внесу свои 3 коп. на правах сугубо IMHO

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

Как один из красивых вариантов разделения логики на промежуточный и серверный слои (иногда - оптимальный, иногда - нет) я бы рассмотрел такой:

- На сервер выкладываем логику. связанную с поддержкой ограничений и целостности в самом широком смысле, поддержку избыточности (денормализации) + массовые сервисные операции (ФИФО/ЛИФО, переоценка/резервирование, начисление доходов по остаткам, вычисление средневзвешенных и среднепотолочных и т.д). Причем, на сервере более естественно мыслить не в терминах объектов, а в терминах чистых реляций (а по этому и язык более естественен PL/SQL или TSQL).

- В промежуточный слой выносим бизнес-логику в узком смысле, связанную с манипулированием данными как бизнес-объектами (такие методы как послать/получить, оплатить, отгрузить, сформировать счет-фактуру и т.д. ). Здесь более уместно объектное представление с иерархией, причем объекты могут представлять собой сложные структуры (агрегаты) с коллекция подобъектов.

Разделение это конечно очень условно и субъективно.

Другая проблема - какие методы/процедуры давать пользователю настраивать под свои нужды, а какие нет. Меня всегда коробит, когда поддержка пользователя может свободно менять все что угодно на сервере, надежностью тут и не пахнет. А как искать ошибку в случае чего, как обновлять при обновлении версии, когда не знаешь, какие ограничения из заложенных разработчиком поддерживались, а какие нет. Но в то же время совсем не пускать пользователя на сервер то же жестоко - часто работать будет невозможно.
Опять же сугубо IMHO как иногда возможное решение. Нужно разделить всю логику (объекты, процедуры) на две зоны - доступные для изменения только разработчиками, и разрешенные для изменения подержкой пользователя (или даже на три - для разработчиков, для собственной службы внедрения, и для подержки пользователя).
Доступ с методам ядра ограничивается техническими и юридическими средствами (шифрование процедур, поставка только компилированного кода, ограничение прав, копирайт, отказ от обслуживания/исправления ошибок в случае нарушения и т.д. в меру испорченности фантазии), прочие процедуры поставляются в исходном коде и копирайт на них распространяется с изъятиями.
Но это IMHO перпендикулярная проблема к разделению по слоям - как ядерные так и пользовательские процедуры/объекты могут быть везде - на клиенте, в промслое, на сервере.


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

iscrafmBogdanov Andreyбизнес-логика более удобно формулируется в других терминах и использование ООП для ее выражения предпочтительнее.
по своей сути, бизнес-логика более естественно описывается и представляется декларациями или функциями. Ну уж никак не объектами. Как и случае с ORM, под объекты она "подгоняется", т.е. функции бизнес-логики транслируются в методы объектов и т.п., образно.

А вот никак не могу согласиться!
Тупой и корявый пример, просто для иллюстрации:
Берем Счет
Проверяем оплату
По счету формируем накладную
По накладной оформляем отгрузку, в частности - формируем счет-фактуру
и т.д.
Чистые объекты и действия над ними, и не надо задумываться об их внутренней структуре и прочих деталях. Все документы - наследники абстрактного класса "Документ", имеют общие методы (регистрируются в журнале входящих/исходящих, посылаются по почте, печатаются и проч.)
Очень естественно и описывается на русском языке, и напрямую транслируется в объекты и методы.

А вот при составлении отчетности проще мыслить в терминах сущностей реляционной модели, объекты только мешаются (извлечь количество и сумму продаж из накладных по 5 товарам с максимальными объемами продаж - зачем тут объекты?)

И при реализации методов объектов, особенно таких, при которых выполняются массовые действия, часто проще мыслить в терминах сущностей реляционной модели. Из другой области:
Во всех счетах, таких что остаток больше нуля, начислить доход на остаток
Здесь Счет будет при реализации таблица "Счет" (банковский), а начисление дохода можно реализовать небольшой ХП.

Никакой религии, я так вижу (с)! Объектно-реляционный дуализьм, природу мать вашу не обманешь:))