В MVVM ViewModel или Модель должны реализовать INotifyPropertyChanged?
После просмотра «Почтальона» удалось найти проблему. Вот решение. Проблема заключалась в операторе with open и, в частности, в параметре position для очищенной части, поскольку длина содержимого автоматически переопределялась, поэтому пришлось получать длину содержимого из запроса ответа.
files={'file':('Sample',open('D:/FilePath/Demo.txt','rb'))}
length=os.stat('D:/FilePath/Demo.txt')
filesize=str(length.st_size)
header = {
# 'Content-Type': 'text/plain',
'Authorization': "Bearer " + auth_t
#'If-None-Match': "*" #Conditional HTTP Header
}
header_append = {
'Content-Length': filesize,
'Authorization': "Bearer " + auth_t
#'If-None-Match': "*" #Conditional HTTP Header
}
header_flush = {
'Content-Type': "application/x-www-form-urlencoded",
'Content-Length': '0',
'Authorization': "Bearer " + auth_t,
#'If-None-Match': "*" #Conditional HTTP Header
}
header_read = {
# 'Content-Type': 'text/plain',
'Authorization': "Bearer " + auth_t,
#'Range': 'bytes=300000-302591'
#'If-None-Match': "*" #Conditional HTTP Header
}
try:
init_put=requests.put('https://adlstorageacc.dfs.core.windows.net/adobe/2019/02/DemoStreamFile4.txt?resource=file&recursive=True', headers=header_flush, proxies=proxies,verify=False)
init_write=requests.patch('https://adlstorageacc.dfs.core.windows.net/adobe/2019/02/DemoStreamFile4.txt?action=append&position=0', headers=header_append, proxies=proxies,verify=False,files=files)
flush_length=init_write.request.headers['Content-Length']
flush_url='https://adlstorageacc.dfs.core.windows.net/adobe/2019/02/DemoStreamFile4.txt?action=flush&position=' + str(flush_length)
init_flush=requests.patch(flush_url, headers=header_flush, proxies=proxies,verify=False)
except Exception as e:
print("In Error")
print(e)
6 ответов
Я бы сказал, что совсем наоборот, я всегда помещаю свой INotifyPropertyChanged в мою ViewModel - вы действительно не хотите загрязнять вашу модель довольно специфической функцией WPF как INotifyPropertyChanged , этот материал должен находиться во ViewModel.
Я уверен, что другие не согласятся, но я так работаю.
Это зависит от того, как вы реализовали свою модель. Моя компания использует бизнес-объекты, подобные объектам Lhotka CSLA, и широко использует INotifyPropertyChanged во всей бизнес-модели.
Наш механизм проверки в значительной степени полагается на уведомление об изменении свойств через этот механизм, и он работает очень хорошо. Очевидно, что если вы используете иную реализацию, отличную от бизнес-объектов, где уведомление об изменениях не столь критично для операции, у вас могут быть другие методы для обнаружения изменений в вашей бизнес-модели.
У нас также есть Модели представления, которые распространяют при необходимости изменяется от Модели, но сами Модели Представления прислушиваются к изменениям базовой Модели.
Я бы сказал в вашей ViewModel. Это не часть Модели, поскольку Модель не зависит от пользовательского интерфейса. Модель должна быть «все, кроме бизнес-агностика»
В MV-VM ViewModel всегда (модель не всегда) реализует INotifyPropertyChanged
Ознакомьтесь с шаблоном / инструментарием проекта MV-VM из http://blogs.msdn.com /llobo/archive/2009/05/01/download-mv-vm-project-template-toolkit.aspx.
Он использует DelegateCommand для командования и должен быть отличным стартовым шаблоном для ваших проектов MV-VM.
Но иногда (как в этой презентации текст ссылки ) модель представляет собой услугу, которая предоставляет приложению некоторые данные в режиме онлайн, а затем вам нужно выполнить уведомление о том, что пришли новые данные или данные изменено с помощью событий ...
Я категорически не согласен с концепцией, согласно которой модель не должна реализовывать INotifyPropertyChanged. Этот интерфейс не является специфичным для пользовательского интерфейса! Он просто информирует об изменении. Действительно, WPF активно использует его для идентификации изменений, но это не означает, что это интерфейс пользовательского интерфейса.
Я бы сравнил это со следующим комментарием: "Шина - это принадлежность автомобиля". Конечно, это так, но велосипеды, автобусы и т.д. также используют их. В общем, не воспринимайте этот интерфейс как UI-штуку.
Сказав это, я не обязательно считаю, что модель должна предоставлять уведомления. На самом деле, как правило, модель не должна реализовывать этот интерфейс, если только в этом нет необходимости. В большинстве случаев, когда серверные данные не передаются в клиентское приложение, модель может быть несвежей. Но если вы слушаете данные финансового рынка, то я не вижу причин, почему модель не может реализовать этот интерфейс. В качестве примера, что если у меня есть логика, не относящаяся к пользовательскому интерфейсу, например, служба, которая при получении цены Bid или Ask для заданного значения выдает оповещение (например, по электронной почте) или размещает ордер? Это может быть возможным чистым решением.
Однако существуют различные способы достижения цели, но я бы всегда выступал за простоту и избегание избыточности.
Что лучше? Определять события по изменению коллекции или свойства в модели представления и передавать их в модель или заставить представление внутренне обновлять модель (через модель представления)?
В итоге, когда вы видите, что кто-то утверждает, что "вы не можете сделать то или это", это признак того, что он не знает, о чем говорит.
Это действительно зависит от вашего случая, и на самом деле MVVM - это фреймворк с множеством проблем, и я еще не видел единой реализации MVVM для всех.
Я хотел бы иметь больше времени, чтобы объяснить множество вариантов MVVM и некоторые решения общих проблем - в основном предложенные другими разработчиками, но, думаю, мне придется сделать это в другой раз.