Оконное приложение с учётом MVVM. Алгоритм конструирования для латунных чайников

@ImedaParishvili · Регистрация: 06.10.2018

Студворк — интернет-сервис помощи студентам

В продолжение своих попыток допилить утилиту, задуманную давно, но подвешенную в список "не срочно" надолго - дошёл до критической точки в понимании, что нельзя просто взять черновик программы на java и сделать из этого рабочее приложение на wpf, и всё потому, что я делаю это неправильно.
Решил попробовать вернуться в самое начало и разобраться с вещами, которые не прижились с наскока в моём представлении о том как оно должно бы быть.
Проблем с рабочей логикой нет, это вещи не слишком зависимые от языка и структуры приложения. Потому решил для себя сформировать от начала алгоритм создания приложения, правильный с точки зрения философии wpf. Основную часть бизнес-логики опускаю из примеров для наглядности, и прошу всех проходивших мимо, но задержавшихся разбирающихся в сабже, по возможности откритиковать получающийся алгоритм.

Конкретизация постановки задачи:
Оконное приложение для создания, сохранения в файл, просмотра и редактирования файлов, содержащих в XMS объект класса Profil

Ориентируемся на MVVM модель-представление-модель представления
Начинаем от модели
1. Создаём класс Profile.cs со всеми полями необходимыми для писания объекта и методами для изменения объекта всеми необходимыми образами

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
namespace Imeda.TP.ProfilDesigner
{
    public class Profil
    {
        private string name;
    private List<Curve> curves;
public Profil(string n)
        {
            name = n;
            this.curves = new List<Curve>();
}
public void AddCurve(Curve c)
        {
            this.curves.Add(c);
        }
public string getName ()
        {
            return name;
        }
 
        public void setName (string n)
        {
            this.name = n;
        }
}
}

2. Создаём класс модели public class TPPDModel.cs, в качестве поля создаем рабочий экземпляр класса Profil profil, в качестве методов всё необходимое для работы с файлом и преобразования объекта в xml и обратно.

3. Создаём MainWindow и закладываем основу макета окна
4. Работа в процессе Coming soon

@Элд Хасп · 30.01.2019, 23:10

ImedaParishvili, а вопрос в чём?

@ImedaParishvili · 31.01.2019, 18:29 **[ТС]**

Дополняя пункт два началом класса, описывающего модель:

2. Создаём класс модели public class TPPDModel.cs, в качестве поля создаем рабочий экземпляр класса Profil profil, в качестве методов всё необходимое для работы с файлом и преобразования объекта в xml и обратно.

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 class TppdModel
    {
        public Profil profil;
 
        void loadProfil ()
        {
            try
            {
                XmlDocument xDoc = new XmlDocument();
                 xDoc.Load ([U][COLOR="Red"]имяфайла[/COLOR][/U]);
            }
            catch(Exception e)
            {
                MessageBox.Show("File's not finded");
            }
        }
    }

Сообщение от Элд Хасп

а вопрос в чём?

Ну вот с этого момента и начинаются вопросы, потому что я не могу сообразить как это правильно архитектурно:

Откуда в методе модели возьмётся это самое имя файла, правильно ли я понимаю что оно - часть представления, которое mVvm, и должно быть что-то типа

C#
1
2
3
4
5
6
7
void loadProfil ([B]string FilePath[/B])
        {
            try
            {
                XmlDocument xDoc = new XmlDocument();
                 xDoc.Load ([B]FilePath[/B]);
}}

Правильно ли теперь в коде MainWindow инициализировать экземпляр класса TppdModel?

Ну и в догонку: а что в WPF вместо MessageBox?

@Элд Хасп · 31.01.2019, 20:37

Сообщение от ImedaParishvili

Откуда в методе модели возьмётся это самое имя файла, правильно ли я понимаю что оно - часть представления, которое mVvm, и должно быть что-то типа

Глубоко в структуре Вашего приложения не разбирался. Поэтому общие советы (по моему виденью)
Если имя файла статично и жёстко связанно с данными (настройки, БД, инет-ссылка и т.п.), то его можно прописать в Модель.
Если имя файла меняется пользователем, то оно должно задаваться из View. При этом диалоги OpenFileDialog и SaveFileDialog это тоже View. Поэтому можно через них задавать.

Сообщение от ImedaParishvili

Правильно ли теперь в коде MainWindow инициализировать экземпляр класса TppdModel?

Нет. View не может ничего знать о Модели. Если какие-то данные нужны - View обращается к VM, а уже VM, при необходимости, инициализирует Модель или один из классов Модели.

Сообщение от ImedaParishvili

Ну и в догонку: а что в WPF вместо MessageBox?

Так же MessageBox, но из пространства System.Windows

@Элд Хасп · 31.01.2019, 20:59

Сообщение от ImedaParishvili

как это правильно архитектурно:

Создайте в решении семь проектов по такой схеме

Оконное приложение с учётом MVVM. Алгоритм конструирования для латунных чайников

Типы проектов:
View - WPF приложение
Консоль - консольное приложение
View библиотека, ViewModel, VM библиотека, Model, Model библиотека - библиотека классов.

Если используете UC элементы, создайте для них восьмой проект типа Библиотека WPF элементов.

@Элд Хасп · 31.01.2019, 21:41

ImedaParishvili, и ещё. Посмотрел Вашу реализацию класса TppdModel. В Модели категорически не должно быть ни какого взаимодействия с пользователем!
В том числе вывода сообщений об ошибках. Представьте, что Модель работает на стороннем сервере. Что, куда, и для кого она будет выводить?
Просто генерируйте ошибку, а обрабатывайте её в VM.

Добавлено через 3 минуты
Я сам делал подобную ошибку и меня поправили в своё время. Посмотрите пост #11 в теме Пример реализации WPF+MVVM приложения в цикле Готовые решения, примеры и рекомендации начинающим на WPF [Элд Хасп]

@ImedaParishvili · 01.02.2019, 10:17 **[ТС]**

Вечером подумаю над этим более разумно, но сходу кроме жалоб на тяжкую судьбу ещё вопрос:
Если делить всё на кучу проектов (я начинал в sln один проект в котором сложено всё) то в чём заключается логика выделения различных Model и ModelLib. И то и то - библиотеки классов, описывающие моделируемое программой сущность. Какие классы куда и зачем их несколько вообще?

@Элд Хасп · 01.02.2019, 11:15

Сообщение от ImedaParishvili

Если делить всё на кучу проектов

Делить надо в целях обучения. Когда в решении нет ссылки из View на Model, то и не возникнет даже вопроса о том - можно ли в View инициализировать какой-то класс Модели? В реальных приложениях, такое полное разделение возникает в масштабных приложениях которые реализуются большими коллективами. Где над каждым проектом (или даже частью его) работает отдельная группа программистов.

Когда у Вас твердо сложится понимание, что к какой части принадлежит, что откуда доступно, постоянное следование такой схеме будет необязательно. Порой для очень частных случаев всё MVVM помещают в один класс или файл. Но нужно держать в голове чёткое понимание того, где данные, где их отображение и где методы согласующие данные с отображением. Поэтому на начальном этапе обучения, советую всегда явно разделять все части MVVM по предложенной схеме.

Сама реализация начинается с Модели и её отладку надо делать в консольном приложении. Когда модель будет отлажена, то создать View и ViewModel DataDesigner (Модель представления времени разработки - далее VMDD).

После создания View создаёте ViewModel как наследника от VMDD и прописываете там необходимые методы для связи с Моделью.

Сообщение от ImedaParishvili

чём заключается логика выделения различных Model и ModelLib. И то и то - библиотеки классов, описывающие моделируемое программой сущность. Какие классы куда и зачем их несколько вообще?

Это больше связанно с удобством для компиляции. Допустим классы описывающие данные создаются в самом начале. В них прописываются все необходимые свойства и способы сериализации, парсинга. В Вашем примере это класс Profil. Потом в дальнейшем эти классы не меняются. Когда пишется модель использующая эти классы, то приходится при любом изменении эти классы перекомпилировать. Чтобы не делать этого, лучше их вынести в отдельную библиотеку. Они будут скомпилированы один раз и больше их трогать не будут. Так же возможно использование каких-то сторонних библиотек (их исходных кодов). То же зачем их держать в Модели?

Кроме компиляции, так просто удобнее. Даже в небольших решениях порой возникает очень много классов. И просто держать их в одном проекте одной кучей - неудобно, трудно находить, то что нужно. Дополнительно даже в рамках проекта ещё и папки в них создаются. А в реальных приложениях, для работы с реальными классами - количество классов очень большое. Вот сейчас пишу небольшое приложение для работы с биржей. Так классов набралось уже под сотню. Если их держать в одном проекте - то чёрт ногу сломит.

Вам же это пригодится в учёбе для получения необходимого в дальнейшем опыта.

На уровне ViewModel есть ещё и другой фактор. View ссылается на классы VM. Но VM создаётся позже View. Так на что ссылаться View? Даже, указанный выше класс VMDD где создавать? Единственное место это ViewModel библиотека. Потом уже ViewModel будет или использовать эти классы или создавать собственные как наследников от этих классов.

@ImedaParishvili · 05.02.2019, 18:39 **[ТС]**

Сообщение от Элд Хасп

Типы проектов:
View - WPF приложение
Консоль - консольное приложение

Итак, как я понял ваш совет: нужно возвращаться к стратегии, с которой я, то ли прочитав книгу какую, то ли где ещё увидев, начал некоторое время назад в вижал студиё. То есть для начала собрать полностью костяк классов для бизнес логики и сделать первично работающую полноценную библиотеку классов. Я дошёл до момента когда среда сказала: "А теперь сделай консольку для отладки, иначе собирать проект я не буду" и скатился к старой привычной стратегии, которая вполне прокатывала на яве без заморочек на разграничения и каноничность кода с точки зрения ООП -- делал сразу настольное приложение со стремлением чтобы на каждом этапе оно собиралось и работало с целью отладки того что я постепенно дописываю в том, что нынче называется "библиотека Model".

Осталось понять что из себя должно представлять то консольное приложение.

@Элд Хасп · 05.02.2019, 22:08

Сообщение от ImedaParishvili

без заморочек на разграничения и каноничность кода с точки зрения ООП

WPF так же можно сделать всё в одной куче в CB окна. Но такой опыт для обучения ничего не даст. Для обучения, нужно явное разделение по проектам. Когда научитесь, тогда уже сможете сами делать оптимальный выбор как реализовывать с разделением или нет.

Добавлено через 58 минут

Сообщение от ImedaParishvili

Осталось понять что из себя должно представлять то консольное приложение.

Модель - это набор кода для работы с данными. Она не должна содержать ни какого визуального интерфейса для пользователя. Просто представьте себе, что эта часть приложения работает удалённо на сервере.

Консольное приложение - это консольный проект. Что в нём может быть не понятного?

Допустим. Модель состоит у Вас из трёх свойств принимающих два операнда и код операции над ними, одного события сообщающего об изменении результата операции и метода возвращающего результат.

Консольное приложение выводит меню из трёх пунктов:
- первый операнд
- второй операнд
- оператор

При вводе любого из них, они отправляются в Модель. Но результат не считывается.

И нужно сделать "прослушку" события модели. Если результат изменился - он автоматически должен быть выведен на консоль.

Новые блоги и статьи Все статьи Все блоги /
Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .
Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025

@Элд Хасп Модератор 16113 / 11234 / 2887 Регистрация: 21.04.2018 Сообщений: 33,035 Записей в блоге: 2
	30.01.2019, 23:10
	ImedaParishvili, а вопрос в чём? 0

@Элд Хасп Модератор 16113 / 11234 / 2887 Регистрация: 21.04.2018 Сообщений: 33,035 Записей в блоге: 2
	31.01.2019, 21:41
	ImedaParishvili, и ещё. Посмотрел Вашу реализацию класса TppdModel. В Модели категорически не должно быть ни какого взаимодействия с пользователем! В том числе вывода сообщений об ошибках. Представьте, что Модель работает на стороннем сервере. Что, куда, и для кого она будет выводить? Просто генерируйте ошибку, а обрабатывайте её в VM. Добавлено через 3 минуты Я сам делал подобную ошибку и меня поправили в своё время. Посмотрите пост #11 в теме Пример реализации WPF+MVVM приложения в цикле Готовые решения, примеры и рекомендации начинающим на WPF [Элд Хасп] 2

@ImedaParishvili 1 / 1 / 0 Регистрация: 06.10.2018 Сообщений: 6
	01.02.2019, 10:17 [ТС]
	Вечером подумаю над этим более разумно, но сходу кроме жалоб на тяжкую судьбу ещё вопрос: Если делить всё на кучу проектов (я начинал в sln один проект в котором сложено всё) то в чём заключается логика выделения различных Model и ModelLib. И то и то - библиотеки классов, описывающие моделируемое программой сущность. Какие классы куда и зачем их несколько вообще? 0