WPF. MVVM. OpenFileFialog (murr-4)
кто из этих трех, model, viewmodel, view должен бы показать диалог?
нагуглил кучу длиннющих обсуждений, с различными вариантами "решений". вот одно из них, например:
https://documentation.devexpress.com/WPF/114757/MVVM-Frame...
да, там какие-то даже байндинги понапихивали, и это все - только чтобы выдать это за mvvm. но я полагаю, что выяснить имя файла - это относится к business logic, responsibility of model, а не viewmodel,. которая только для того, чтобы связывать правильно model и view, чтобы ни одна из них друг другом не заморачивалась. а они показывают диалог в конечном счете именно в viewmodel, которой не должно быть до этого дела.
в конце концов, если модели нужно запросить что-то в интернете, оно берет и запрашивает. или имеет кого-то, кто для нее это сделает. здесь - имеется готовый отлаженный диалог. почему, когда мадель решила, что ей нужно выяснить, с каким файлом работать, она не может с помощью одной строчки когда его получить? почему это - тяжкий грех, и лучше нагородить для соблюдения канонов несколько страниц всяческого кода? чтобы было что юниттестировать?
кто из этих трех, model, viewmodel, view должен бы показать диалог?
диалог - view :)
в конце концов, если модели нужно запросить что-то в интернете, оно берет и запрашивает. или имеет кого-то, кто для нее это сделает. здесь - имеется готовый отлаженный диалог.почему, когда мадель решила, что ей нужно выяснить, с каким файлом работать, она не может с помощью одной строчки когда его получить?
Ну ведь не просто так придумали разделение на бизнес логику и отображение. Бывает еще так, что программа должна работать в режиме без GUI и согласись, будет странно, если модель вдруг откроет окошко :D
почему это - тяжкий грех, и лучше нагородить для соблюдения канонов несколько страниц всяческого кода? чтобы было что юниттестировать?
Правила существуют чтобы их нарушать :) Никто тебя не расстреляет, если откроешь диалог из модели. Впрочем, открыть диалог и установить родителем главное окно у тебя не получится.
Правила существуют чтобы их нарушать :) Никто тебя не расстреляет, если откроешь диалог из модели.
Чойта? Лично расстреляю, если такое на ревью всплывёт. Один раз пропустишь, потом оглянуться не успеешь - вся модель в опросах чекбоксиков и активации/деактивации скроллбаров будет.
0. опенфайлдиалог никак не привязан к вашему вью. не хотите его прямо из модели показывать, сделайте "нечто" с интерфейсом "дай файл", и покажите диалог там.
1. чтобы из модели контролировать чекбоксы и вообще что-то из вашего вью, нужно сильно исхитриться, т.к. модель вообще без понятия, что ее показывают.
2. вы в последний раз проводите ревью?
если уж ваша церковь требует, чтобы все, что на экране - это вью, тогда откройте диалог просто в код бихайнд и присвойте имя файла чему-нибудь в xaml, что можно прибайндить к чему-нибудь в вьюмодели, чтобы она узнала, что появилось имя файла, которое нужно вставить в модель.
фанатики от mvvm, как и в любой другой религии - это плохо и не признак э-э-э... ладно, проехали.
Чойта? Лично расстреляю, если такое на ревью всплывёт.
Мне кажется, что на ревью надо руководствоваться здравым смыслом, а не религией. Вполне возможно, что где-то в архитектуре была допущена ошибка (как иначе может получиться, что модель должна взаимодействовать с пользователем?), исправление которой очень дорого, а фича нужна вчера. При этом никто не мешает тебе создать задачу на исправление этой ошибки ;)
надо руководствоваться здравым смыслом, а не религией
-----
Здравый смысл говорит, что если есть разделение - его надо соблюдать.
Ибо несоблюдение выливается в очень большую головную боль...
Если нужен пример несоблюдения - возьми мелкософтовский компилятор Т4-шаблонов
и добавь в генерируемый код один метод.Там не много - буквально 5-7 строк.
А после того как сделаешь - дай возможность использовать оба варианта...
чего это будет стоить - не знаю - там смешаны парсинг, генерация... и взаимодействие со Студией...
а фича нужна вчера
------
Ну это как обычно - вчерашние фичи пишет менеджер... у него для этого машина времени есть... 
При этом никто не мешает тебе создать задачу на исправление этой ошибки ;)
Исчо б ещё и мешали... А когда вы в последний раз получали возможность обработать такую задачу? Наращивать tech debt много ума не надо, а вот как потом эту гору разгребать - не знает никто.
Вполне возможно, что где-то в архитектуре была допущена ошибка (как иначе может получиться, что модель должна взаимодействовать с пользователем?)
1. Если есть ошибка надо её исправлять, а не бить окна. (И да, я понимаю что прибегают истерящие менеджеры воющие про вчера и срочно, мне не сложно с ними к руководству пройтись, после чего процентов 70 задач сразу испаряются, ведь свой косяк показывать руководству менеджер не хочет, а в оставшихся случаях 50 на 50, что руководство посчитает важнее - срок сейчас или долговременное влияние на проект)
2. Кто сказал что есть ошибка? Насколько я понял оратора ему просто лень информацию до вью пробрасывать.
ну почему лень? я просто понимаю так, что если нужно ВСЕГДА действовать самым прямым, простым и всем понятным способом. в случае с опенфайлдиалог как правило потребность в выборе файла становится известна гуи, и самое простое - там все и решить, не вовлекая никого в процесс. т.е. в случае впф (мввм или нет) - обработать событие непосредственно в кодбихайнд (для того он и есть, чтобы имплементировать "гуи-логику"), и каким-нибудь путем уж, если мы - члены церкви мввм, воткнуть выбранный файл в "модел".
кстати, модел - дурацкое слово, выбранное John Gossman для этой части приложения, так как интуитивно напрашивается ассоциация с какими-то "данными". а по сути модел - это вся бизнес-логика. т.е. все за исключением презентэйшн.
сегодня John Gossman манагерит эйджэр. и вообще насколько мне известно, он сам ничего не создал, только "технологии", "архитектуры", и под мввм он имел ввиду не "надо вот так", а "а вот иногда бывает вот так очень удобно".
если партия произнесла слово "кукуруза", это не означает, что всем следует все поля засеять только кукурузой. я не виню John Gossman, как не винил никогда никиту сергеевича. просто "загадай дурному богу молиться, так він і лоба розіб’є". вот я о чем.
зы. а как вы вообще приступаете к созданию нового продукта? я имею ввиду from scratch, а не когда уже что-то есть, и нужно просто приналадить под нового клиента? если приходилось, конечно. знаю, большинство чаша сия минует на протяжении всей их жизни.
потребность в выборе файла становится известна гуи
Ну так там его и оставить, как и говорили, во View, никак не могу понять в чём проблема. Отлично все ложится на MVVM. VM дает команду, она обрабатывается, результат поступает назад. Меня больше смущало что винформс вызовы нужно пользовать.
а как вы вообще приступаете к созданию нового продукта?
Каждый видимо поступает как ему удобнее, да и от продукта и ситуации зависит.
Для начала нужно описание функциональности, затем выработать концепт, а после по частям его делать.
Ну так там его и оставить, как и говорили, во View, никак не могу понять в чём проблема.
да если все во вью, никаких проблем вообще. или если не привязывать показ диалога ни к каким фрэймворкам.
Отлично все ложится на MVVM. VM дает команду, онаобрабатывается, результат поступает назад.
вот видите, вы уже зацепили вм. а это ужо не вью. какого хера (-с) вм дает какие-то команды вообще? кто оно такое?
одним из теоретических преимуществ вммв (или мввм? какая *й разница : ) является утверждение, что таким образом можно разделить команды разработчиков вью, модел и вьюмодел так, что они вообще ничего друг о друге не должны знать. это - апофеоз всей этой истории! в идеале мы вообще набираем три команды разработчиков, которые меж собой очень мало коммуницируют, очень мало знают, что разрабатывается вообще, и, идеально, находятся на разных континентах.
еще идеальнее. набираем три команды разработчиков. одна разрабатывает вью. перфект! красиво! клиент пойдет как камса в путину!
вторая разрабатывает модел - чтобы была хорошей, и не знала вообще, как она представлена во вью (и имеет ли она вью вообще. какого хера!)
ну, а вьюмодельщики сцепят их обоих без проблем. сюда набирают гениев. они тоже без понятия, что разрабатывается, для чего и т.д., но главное - они умеют выступать посредниками между вьющиками и моделщиками.
и вообще нахера в начале проекта заморачиваться тем, зачем нужен проект? не лучше ли подождать развития событий, и потом, когда что-то вырисуется, определить цели?
:::)))))))
извините, но для меня это выглядит как надувание щек. это когда "по существу заданных мне вопросов" - полный ноль, зато слова о новичках, сущностях и прочих ниочемах.
вопрос очень простой, и он четко сформулирован в заголовке и первом посте. как в мввм показать опэнфайлдиалог. предлагаете сделать его отдельной сущностью? : )
какого хера (-с) вм дает какие-то команды вообще?
А кто по вашему отвечает за обработку команд?
Пользователь нажимает кнопу "хачу файл" (ICommand у меня сидит в ВМ), обработчик команды посылает сообщение - надо бля файл открыть, патаму как я нимагу у мну нету доступа ко вью пространству.
Вьюва подписана на команду "выбрать файл" и открывает диалог выбора, после выбора отдает имя файла ВМ если он выбран.
Где Вы видите проблемы? Кстати, в моделях у меня только ПОКО объекты и никакой логики.
одним из теоретических преимуществ мввм
Где Вы находите подобную теорию я не знаю 
Невозможно делать одну штуку из трех частей не имея никаких точек соприкосновения.
и вообще нахера в начале проекта заморачиваться тем, зачем нужен проект?
Ну пож. не заморачивайтесь. Можно и из пушки по воробьям стрелять, как туты любят грить.
Предисловие. Что-то я не в настроении был поддерживать заданный стиль общения, ну, вроде "если ваша религия запрещает вам думать прежде чем разевать хлебательное отверстие, то не надо вываливать всё это в форум" и не собирался вам отвечать. А сейчас что-то время появилось, дай, думаю, все же попробую объяснить, не только же вы форум читаете.
Значицца... Начнём с откровения
он имел ввиду не "надо вот так", а "а вот иногда бывает вот так очень удобно".
Вообще-то так можно сказать про все паттерны и/или архитектурные принципы. Для каждого есть подходящие условия, когда их полезно использовать, и неподходящие условия, когда их использовать просто вредно. Тот же монолит (хотя его любят путать с big ball of mud) часто выгоднее (удобнее) чем накручивать модные микросервисы.
Но вот после того, как для проекта выбраны паттерны и принципы, которыми мы хотим пользоваться, менять их просто потому что кому-то захотелось нарушить их и сделать что-то по-другому, особенно если этот кто-то просто не понимает что же ему даёт паттерн,который он с негодованием требует выбросить, вот этого делать категорически нельзя. Через расстрел в ревью.
Вашим языком - в начале проекты мы выбираем себе религию. И в этом проекте религию не меняем. До тех пор пока не понимаем, что она нас не устраивает потому что ... (здесь список проблем). Тогда меняем на то, что может решить эти проблемы.
Пример: в начале проекта Z речь шла о десктопном приложении, которое должно легко и быстро устанавливаться любой секретаршей, нужно только на год-два, пока не заработает проект Х (с веб-интерфейсом, десктопным и андроидным клиентом, одновременно поддерживающим до 100к запросов в минуту и те пе) никакой поддержки не надо. Что лепим? Монолит. Структуру стараемся сильно не нарушать, но главное - стоимость, потому что всё равно выбрасывать и поддерживать не надо. Фанатично отвергаем всякие "а давайте вынесем модуль для рассылки почты в облако" или "а давайте сделаем чёткий интерфейс между GUI и бэкендом". Не надо. Быстро слепили и в продакшен. Но. Проходят полгода и гениальные менеджеры внезапно меняют решение. И радуют всех своим решением - так как Х задерживается, и вообще что-то слишком много стоит, мы его закрываем, а ваш Z очень понравился всем секретаршам, мы просто расширим его функциональность до той, которую обещал нам X, и начнём поддерживать его добавляя новые фичи по требованию клиентов в течение следующих н-цати лет. Вы же за полгода написали с нуля? Ну вот вам еще целый год, и штоп было сделано! Вот тут придется менять религию. Потому что с монолитом такого размера мы через 3 месяца скатимся к комку грязи.
я просто понимаю так, что если нужно ВСЕГДА действовать самым прямым, простым и всем понятным способом
Отож. Осталось разобраться какой же способ для всех понятный, самый прямой и простой. И полетим к звёздам. Завтра же. Кстати, а как вы понимаете для чего нужны паттерны? Можете буквально в 1-2 предложения написать? (можно больше)
одним из теоретических преимуществ вммв (или мввм? какая *й разница : ) является утверждение, что таким образом можно разделить команды разработчиков вью, модел и вьюмодел так, что они вообще ничего друг о друге не должны знать.
Что вы курите и откуда такое берёте? Хотя, не удивлюсь если найдётся цитата кого-нибудь из мелкософта, они всегда отличались умом и сообразительностью.
а как вы вообще приступаете к созданию нового продукта?
Последние два раза по скрамовской методичке - с менеджментом определяем product vision, MVP, personas. Пара встреч с заказчиками и предположительными клиентами, заставляем родить несколько user stories. Потом определяемся с менеджментом с нефункциональными требованиями и их приоритетом, вместе с командой выбираем религию для проекта. После пары спринтов, ревью и пожеланий ПО, хватаемся за голову, меняем религию, воюю с менеджментом, объясняю почему надо выбросить всё и начать заново, выбрасываем половину, работаем дальше.
"дискуссия" показала, что существует не только мввм-религия, но внутри нее - масса различных церквей и сект, претендующих на исключительные устанавливать ритуалы и облачения.
позволю себе вставить в пост немножко View ; )