Михаил: что хочешь увидеть? Желательно что-то не сильно большое, чтобы это можно было быстро сделать. Так-то могу многое просто скопировать частично в новый проект и довольно быстро сделать новый, но всё же, что именно тебе непонятно и что интересует?
Лично как думаю я, тебе нужно знать, что есть локатор вью моделей (ViewModelLocator), в нём содержатся нужные вью модели. Можно настроить свойства этого класса так, чтобы при обращении они/оно возвращали всегда один и тот же экземпляр вью модели или каждое обращение новый. Либо можно создать лишь реально долгоживущую вью модель в локаторе, а остальные создавать внутри кода других вью моделей уже по мере создания каких-то объектов, которые требуют вью модель. Ну или вью модель может быть изначально в свойстве DataContext какой-то вью. Возможно сейчас ты ничего не понял, но когда попробуешь что-то писать, то вернись к этому тексту, постепенно придёт понимание о чём я говорю.
Как устроен MVVM.
Model - классы модели, то есть бизнес логика и какие-то классы, к примеру DTO (data Transfer Object), с помощью которых можно обмениваться данными через WCF. Сериализовали объект на сервере, передали данные в виде XML, десериализовали на клиенте, вот это DTO.
ViewModel - логика самого приложения и, например, обёртки над DTO классами, которые умеют уведомлять UI о изменении какого-то свойства в DTO классе. В простом случае это просто копия DTO класса, но внутри этой "копии" находится экземпляр класса DTO, а обёртка оборачивает его свойства своими и дополнительно вызывает реализацию INotifyPropertyChanged. Без примеров кода не совсем ясно, но в будущем должен понять, что я тут имею ввиду.
View - окна, элементы управления, в общем, вся UI часть.
Как всё взаимодействует. View знает о ViewModel, ViewModel знает о Model, но не наоборот.
View обновляет свои данные посредством биндингов и вызывая методы вью модели внутри CodeBehind вьюшки. Но нельзя передавать во ViewModel на что-то из View, ведь ViewModel ничего не знает о View.
Зачем всё вообще это нужно? Во-первых написав нормально рабочую ViewModel можно легко заменить View не трогая ViewModel, в хорошем случае. Либо для одной ViewModel можно написать много разных View и в зависимости от своих каких-то условий подставлять нужный VIew. Так же такое разделение позволяет легко тестировать ViewModel в юнит тестах, так как она вообще никак не связана с View. Короче, поверь, одни плюсы. Я уже не раз убедился, что на работе все новые проекты используют MVVM.
Спасибо. Это интересно. А не подскажите, где можно об этом почитать? У меня есть какая-то книга по Win API, но не факт, что там есть эта информация. Или может толковую книгу подскажите?
Александр А: в смысле учитывать? Меняешь свойство на Maximized и окно само должно же принимать нужный размер. Или это работает только, если у окна есть рамка, которой у меня нет.
Лично как думаю я, тебе нужно знать, что есть локатор вью моделей (ViewModelLocator), в нём содержатся нужные вью модели. Можно настроить свойства этого класса так, чтобы при обращении они/оно возвращали всегда один и тот же экземпляр вью модели или каждое обращение новый. Либо можно создать лишь реально долгоживущую вью модель в локаторе, а остальные создавать внутри кода других вью моделей уже по мере создания каких-то объектов, которые требуют вью модель. Ну или вью модель может быть изначально в свойстве DataContext какой-то вью. Возможно сейчас ты ничего не понял, но когда попробуешь что-то писать, то вернись к этому тексту, постепенно придёт понимание о чём я говорю.
Как устроен MVVM.
Model - классы модели, то есть бизнес логика и какие-то классы, к примеру DTO (data Transfer Object), с помощью которых можно обмениваться данными через WCF. Сериализовали объект на сервере, передали данные в виде XML, десериализовали на клиенте, вот это DTO.
ViewModel - логика самого приложения и, например, обёртки над DTO классами, которые умеют уведомлять UI о изменении какого-то свойства в DTO классе. В простом случае это просто копия DTO класса, но внутри этой "копии" находится экземпляр класса DTO, а обёртка оборачивает его свойства своими и дополнительно вызывает реализацию INotifyPropertyChanged. Без примеров кода не совсем ясно, но в будущем должен понять, что я тут имею ввиду.
View - окна, элементы управления, в общем, вся UI часть.
Как всё взаимодействует. View знает о ViewModel, ViewModel знает о Model, но не наоборот.
View обновляет свои данные посредством биндингов и вызывая методы вью модели внутри CodeBehind вьюшки. Но нельзя передавать во ViewModel на что-то из View, ведь ViewModel ничего не знает о View.
Зачем всё вообще это нужно? Во-первых написав нормально рабочую ViewModel можно легко заменить View не трогая ViewModel, в хорошем случае. Либо для одной ViewModel можно написать много разных View и в зависимости от своих каких-то условий подставлять нужный VIew. Так же такое разделение позволяет легко тестировать ViewModel в юнит тестах, так как она вообще никак не связана с View. Короче, поверь, одни плюсы. Я уже не раз убедился, что на работе все новые проекты используют MVVM.