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

E>Попробую объяснить подробнее.
E>Есть сложный бизнес-сценарий, который читает из БД данные, преобразует их, записывает в преобразованном виде во внешний файл, сохраняет в БД новые сформированные данные.
E>В этом сценарии много ответвлений, условий и "развилок", которые зависят от конкретного состояния данных, от результата выполнения действий с БД и файловой системой.
E>При возникновении этих развилок нужны дополнительные данные, которые надо запросить у пользователя.
E>И выполнение сценария продолжается в зависимости от ответа пользователя.

E>Каким образом запросить данные у пользователя так, чтобы не зависеть от слоя UI?
E>Ведь слой Бизнес-логики не должен зависеть от UI.

E>Очень упрощенный пример.
E>Мы в редакторе сохраняем файл, указываем имя.
E>Бизнес-логика при попытке сохранения файла обнаруживает, что такой файл уже существует.
E>Дальше она задает вопрос пользователю: "Что дальше делать?". Обычно предлагаются следующие варианты "Заменить, Сохранить под другим именем, Отменить".
E>Однако, таких вариантов может быть больше и они определяются возможностями бизнес-слоя.
E>Например, более "продвинутый" бизнес-слой мог бы предложить такие дополнительные варианты действий: "Дописать в существующий файл", "Сохранить под указанным именем переименовав существующий файл" и т. д.

Навскидку, не зная деталей, можно предложить паттерн Strategy. Аналог того, как если бы в алгоритм сортировки нужно было передать частный способ сравнения элементов.

S>>>>Я пытаюсь выяснить, чем лучше архитектура, предложенная Мартином? Но конкретно, а не просто "удобнее". Удобнее чем что? Удобнее чем? Для какого типа приложений?

E>>>Ну какая разница какая архитектура лучше или хуже?
S>>Если разницы нет, бери архитектуру God Project (по аналогии с God Object) и не парься над слоями.

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