Здравствуйте, Tissot, Вы писали:

T>Ладно, сдаюсь, задолбало меня отвечать на ваше изменение условий. Вы сначала сделайте, что хотите, а потом уже и будет о чем говорить. А ток — одна сплошная риторика.
Я таких систем, в общем-то, написал в ассортименте. И с ORM-подходом тоже наелся по самое не хочу.

S>>А теперь расскажи нам, как это работает в случае unit of work. Какие блокировки накладываются в какой момент, и в какой они отпускаются. Учти еще, что характерное время ответа от веб-сервиса — это 200мс, а одиночный апдейт в базе выполнится примерно за 10мс.

T>Я про фому, а ты опять про ерему. В реальной жизни ты не добьешься непересечения под-задач по данным.
Я не виноват, что ты так плохо придумываешь задачи.

T> Хотя бы уже потому, что иначе тебе при каждом изменении нужно будет просматривать все использования изменяемого тобою кода.
Это иллюзия. Понимаешь, это в случае unit of work и "тру-ООП" подхода у тебя модификации хаотически разбросаны по всему коду. И совершенно непонятно, сколько раз и что апдейтится, и нет ли между апдейтами тяжелой операции с вовлечением внешних ресурсов.

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

T>А с учетом того, что предполагается использовать возможности БД на полную катушку, это еще более усложняется.
Упрощается, и сильно упрощается.