Petro123, ничего не имею против десктоп систем, речь идет о 2 tier vs 3 tier , и только :)

Petro123МСУPetro123, ничего не имею против десктоп систем, речь идет о 2 tier vs 3 tier , и только :)
конечно, их много всяких.
Ты бы уточнял, что MS клиент-сервер 2 звена - Г.
И в MS блокировочник СУБД - Г. Т.к. блокирует рессурсы и ложится при незакрытой транзакции.
Про "стул начальника" я не понял.
Зачем мне уточнять? Речь была о логике в хранимых процедурах без наличия сервера приложений. По факту это 2 tier. Причем тут MS? Что именно тебя смутило про стул?

Petro123- БЛ в ХП ничем особым не отличается от БЛ на АппСервере в 3-х звенке.
Смотря какой смысл ты закладываешь в слово "особый". Если для тебя такие понятия как "масштабируемость", "изолированность уровней" и "надёжность" - пустой звук, то пиши дальше бизнес логику в хранимках. А на элементарное бизнес требование по смене СУБД, изменении схемы хранения данных (например, часть схемы мигрирует в Oracle) и т.д. у тебя система раком встанет - потому что ты свои хранимые процедуры будешь обвивать такой дикой логикой, что всё это гумно распухнет до таких масштабов, что хоть кричи хоть плачь. Видывал я такие распухшие недокументируемые априори хранимые процедуры под несколько тысяч строк кода. Такой навоз не то что масштабировать, а сопровождать нереально. Побойся бога, бизнесу нечего делать в хранимых процедурах.

Petro123- ООП при обработке данных в виде кортежей (множеств в учётных системах) не нужен на слое БЛ.
Бизнес логика не так проста, как кажется изначально. Порой это многотонный витееватый иерархический воркфлоу, который совмещает в себе несколько видов СУБД, вебсервисов и прочих внешних ресурсов.

Petro123- Незакрытие транзакции может быть как в вебе (3-х звенка), так и в БД (2-х....)
Атака со стороны клиента выглядит намного реалистичней атаки со стороны сервера приложений. Даже к гадалке не ходи.

Petro123- Если сесть на рабочее место админа, то ни о какой безопасности можно не говорить вообще.
Товарищ начальник или более привилегированный пользователь системы, который даже пароль свой не помнит - это не админ. Это современные реалии, из под учеток которых и ломаются системы. С админом же, как правило, всё в порядке.

Petro123- Время разработки 2-х звенки Относительно меньше чем 3-х....
Я уже писал, выигрыш получишь позже, причем колоссальный.

Petro123из практики - На Delphi - 1 окно в день студентом
Жжешь. Новый вид оценки трудозатрат

Petro123iscrafmПросто выбирается самый простой - заблокировать.
ДА НЕ БЛОКИРУЮТСЯ ОНИ.
Например, в Оракле на каждый рессурс (строка) - ставится метка.
Делай с БД что хочешь хоть полдня. На коммит все метки снимаются и записи переходят из кэша\темпа статуса в коммит статус.
Удобно? Безусловно.
Иначе надо по ОРМ и ООП делать в оперативке кучу взаимосвязанных объектов.
Что тоже решаемо профессионалами).
А что мешает тоже самое сделать с помощью сервера приложений?

Petro123МСУ, жду решение по атомарности, неделимости и изолированности транзакции со сложными объектами.
Ты ж моя прелесть, держи: Transactions in WCF Services . Читай медленно, последовательно и долго. Что непонятно, сразу спрашивай. Когда всё прочитаешь, я расскажу тебе секрет про WS-AtomicTransaction . Он позволяет передавать распределенные транзакции, используя сообщения веб-служб, и обеспечивать взаимодействие между разнородными инфраструктурами транзакций. WS-AT использует протокол двухфазной фиксации для передачи атомарного результата между распределенными приложениями, диспетчерами транзакций и диспетчерами ресурсов. Когда научишься с этим работать, приступим к третьему уроку, как эту богодельню конфигурировать через шелл. Ну и в заключении, я поведаю тебя страшную тайну о том, что такого рода заморочки на транспортном уровне в SOA нужны крайне редко, для самых утонченных архитекторов. Ну что, понеслась? :)

Petro123для сложного объекта с 7-ю ходами визарда
Я сцуко плакал Петро, ты с какой галактики тут к нам пришел? :)

Я, конечно, идеологически осознаю, о чем ты пишешь, но твоя манера объективно выражать свои мысли просто обескураживает :)

Так вот, по поводу "ходов визарда" Сколько не ходи визардом, а объект сидит в базе в оперативной таблице со связкой { Id, UserId, Columns or XML } и ждет, пока его протащат в основную сущность. Пользователь может отключаться, включаться, танцевать польку, играться визардом во всех направлениях, собирая объект. Когда придет время кнопки Finish, объект отлетит туда, где ему и положено быть. В чем проблема?