ну или вот еще пример "правильной" архитектуры. т.е. сейчас чтобы создать диалог с кнопкой выбрать файл надо написать 60 строк кода

[trud]

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

сейчас предлагается объявить класс для реализации стратегии временного хранения(указать кол-во минут после которой файл станет экспайред - кстати тут вообще треш- это прописывается в классе, и непонятно руководствуясь чем прикладной разработчик должен выбирать это время - во многих местах 5мин, в банковской выписке 60 мин), передать его в другой класс - в виде строки, как classStr - это тоже "красиво" конечно, я так понимаю идет эмуляция атрибутов(возвращаясь с исходной теме), создать евент для дизейблинга кнопки ОК на время загрузки, подключить этот евен к событию окончания загрузки файла, снять это событие после окончания загрузки, не забыть еще удалить этот файл из временного хранилища и прочее - и такое повторяется во всех 10-15 классах в стандарте где используется загрузка файлов в диалоге

т.е. какие-то бизнес функции подменяются техническими абстракциями

а кстати есть ли название у такого подхода с передачей класса, это из какого-то существующего языка?
т.е. код вида

Class1 c1 = new Class1();

c1.init(classstr(Class2));