Каким образом отделять UI от логики в «глубоко интерактивном» процессе, и нужно ли вообще?

Пример глубоко интерактивного процесса — обработка файлов по GTD. Схема, например, тут: http://anabubula.com/files/gtd4iphone_diagram001.png

Т.е. есть некоторый процесс, у которого достаточно много состояний; в каждом состоянии для перехода в другое нужно сделать выбор (иногда многовариантный); и почти в каждом из листовых состояний для завершения требуется дополнительный ввод информации различного характера от пользователя. К тому же, все должно происходить быстро и ненавязчиво, поэтому не хочется делать что-то наподобие классического wizard-а.

Сейчас вся логика у меня сидит в коде UI. Положение осложняется тем, что приложение на Cocoa/MonoMac, поэтому (или потому что опыта работы с Cocoa нет) логика в UI-коде теряется; каждое состояние живет в своем методе-обработчике соответствующего события от UI. Хочется как-то по-другому сделать, но к красивому легковесному решению у меня придти не получается, поэтому и пишу.

Всех с наступившим и удачи в новом году!

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

SN>Каким образом отделять UI от логики в «глубоко интерактивном» процессе, и нужно ли вообще?
нужно или не нужно -- вопрос далеко не однозначный. плохое отделение это дополнительные затраты на проектирование и имплементацию, а преимуществ никаких. вместо одной кучи, куда свален интерфейс и логика, мы получили несколько разных куч, прочно связанных друг с другом и по сути представляющих одну большую кучу.

имеет смысл выделять независмые сущности и обособлять их от остального кода. так проще отлаживать и повторно использовать, и т.д., и т.п.