Классы Model в View

@Элд Хасп · Регистрация: 21.04.2018

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

Такой концептуальный вопрос.

Есть, допустим, класс Person (ID, Name, Family) в библиотеке Model (ModelLib). Модель построена, всё отлажено. Выдаёт данные, в том числе типа Person.

Приступаем к созданию View. Но View не имеет информации о классе Person и не может отобразить его свойства.

Можно дать View ссылку на ModelLib, но корректно ли это в рамках MVVM?
Можно сделать в рамках ViewModelDD класс, допустим PersonVM, собирающий нужные свойства из класса Person. Но тогда придётся каждый экземпляр Person оборачивать экземпляром PersonVM.
Можно сделать общую для всех библиотеку и туда запихнуть Person. Но по сути это вариация первого подхода.

Что посоветуете? Как более правильно реализовать в рамках MVVM ?

@Рядовой · 15.02.2019, 08:05

Элд Хасп, а что отображать требуется? один экземпляр класса или массив?

@novikov.ea · 15.02.2019, 09:04

Вариант 1.
Имеются ли какие-то аргументы, чтобы так нельзя было делать?
В общем случае, если нужно просто отобразить данные во вью, то следует использовать класс модели. Если отображение имеет свою дополнительную логику: нужно отобразить значение, вычисленное из других свойств или объектов, обработать пользовательский ввод, иметь на уровне класса команду, то тогда следует создать для класса модели соответствующую ей вью-модель.

@skilllab · 15.02.2019, 10:54

В случае прямого биндинга модели ко View нужно всегда помнить что сделал именно так. Т.е. в случае когда ТОЧНО знаешь что расширенных действий не понадобится (как указал novikov.ea). В противном случае XAML в последствии может жутко разрастись, потом накатится VM, и, в какой либо момент времени, настанет случай кода View будет ссылаться и на VM и на модель. Что приведёт к пипец каким нервам))) и говнокоду.

Добавлено через 2 минуты
Имхуется, что прямой биндинг прям вот необходим в случае простого отображения уже вычисленных данных, информационных сообщений, содержащих значения из модели, окон ошибок ввода или проверок.

@Элд Хасп · 15.02.2019, 14:11 **[ТС]**

Сообщение от Рядовой

что отображать требуется? один экземпляр класса или массив?

Я не конкретном случае, а о самом принципе: Насколько допустимо "знание" View о Model?
В реальных случаях могут быть и отдельные экземпляры, но чаще это проблема возникает конечно для массивов. Так как дублирование свойств одного экземпляра в VM - не затратно. Вот сейчас пытаюсь сделать приложение для работы с сервером. А там Сервер возвращает в ответах списки типизированные несколькими десятками разных классов и сами классы содержат по несколько десятков свойств.

Начал делать"в лоб".... Но чувствую какая-то пурга получается. Или огромное дублирование на уровне VM, или надо делать ссылки из View и на VM, и на Model.

Даже просто наследование классов VM от классов Model не спасает. Всё равно тогда приходится в View делать ссылки на базовые классы Model. Что бы не делать таких ссылок придётся делать классы VM без наследования от Model, но это приводит к большому количеству дублирующего кода.

Сообщение от novikov.ea

Вариант 1.
Имеются ли какие-то аргументы, чтобы так нельзя было делать?

Сомнения в "концептуальной чистоте" кода в отношении паттерна MVVM.

Сообщение от novikov.ea

В общем случае, если нужно просто отобразить данные во вью, то следует использовать класс модели. Если отображение имеет свою дополнительную логику:

Дополнительная логика есть, но её проще реализовать в наследнике от класса Model, но тогда в View придётся всё равно делать ссылку на Model.

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

настанет случай кода View будет ссылаться и на VM и на модель. Что приведёт к пипец каким нервам))) и говнокоду.

Уже настал и привёл...!

Вот если таким образом организовать решение. Насколько это будет "чисто" для MVVM ?

@Рядовой · 15.02.2019, 14:27

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

огромное дублирование на уровне VM

Шаблон Model-View-ViewModel (MVVM) помогает четко отделить бизнеса и логику представления приложения из его пользовательский интерфейс (UI).

https://docs.microsoft.com/ru-... terns/mvvm
Если ответ сервера нужно отобразить на вью, то сам ответ сервера уже относится к логике-представления и должен проходить во VM, с применением классов Model. Если же этот ответ будет обрабатываться - то это часть бизнес логики и должен проходить в модели, а результаты, подлежащие опубликованию, отправляться во VM.
Хоть господа сверху и вещают, что допустимо биндиться напрямую к модели, если это одностороняя привязка, делать этого не не надо. Модель не должна в себе содержать данные для опубликования.

@Элд Хасп · 15.02.2019, 14:45 **[ТС]**

Рядовой, вот такой пример.

Класс Person (ID, Name, Family). Ответ от сервера приходит в формате массива, где ID, Name и Family - это элементы массива. Элементы массива в View я показать не могу. Нужны свойства. Делаю в VM наследника от Person в котором свойства берут свои значения от элементов массива базового класса.

Если View меняет значения свойств, то я без проблем отправляю наследника в Model он сам там дефолтно приводится к базовому классу и сохраняется.

Но! Базовый класс объявлен в Модели и View требует ссылку на Модель. Поэтому и возникла вышеуказанная схема, где классы Модели находятся в отдельной библиотеке и View получает ссылку на эту библиотеку. Но корректно ли это?

Может я слишком узко смотрю и есть какое-то другое более типовое решение?

@Рядовой · 15.02.2019, 14:59

Элд Хасп, если этот Person должен быть отображен во вью, то он должен находится во VM (сам экземпляр). Базовый класс объявлен в модели и служит контейнером, который вы наполняете во VM, а вью отображает

Элементы массива в View я показать не могу

В этом же классе сразу объявите свойства подлежащие отображению

@Элд Хасп · 15.02.2019, 15:12 **[ТС]**

Сообщение от Рядовой

если этот Person должен быть отображен во вью, то он должен находится во VM (сам экземпляр). Базовый класс объявлен в модели и служит контейнером, который вы наполняете во VM, а вью отображает

Да, я так и начал делать.
Но это привело к огромному дублированию кода. Это в примере один класс с тремя свойствами. А в реале десятки классов с десятками свойств....
Возникают сомнения - на том ли я пути...

Часть ответов приходит как нормальные классы. Нормально JSON десериализуются в классы со свойствами. Что с ними делать? Это же классы Модели, а не VM. Если их объявить в VM, то Модель не сможет ими пользоваться. Если Их объявить в Модели, то для View они не доступны. Их тоже использовать просто как контейнер и перезаписывать в классы VM ?

Добавлено через 2 минуты
И подход нужен единообразный. Если часть классов (которые приходят как массивы) использовать как контейнеры, а те что со свойствами стыковать напрямую к View - вообще, какой-то бедлам получится!

@Рядовой · 15.02.2019, 15:25

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

Что с ними делать? Это же классы Модели, а не VM. Если их объявить в VM, то Модель не сможет ими пользоваться.

Если эти данные должны быть и отображены во вью и дальше отправляться на обработку в модель, то ничего не поделаешь. Придется дублировать. Они являются и частью логики отображения и частью бизнес логики.
Получайте данные в модель, заполняйте класс - наследник (как вы и делали) и отправляйте во VM. А оригиналы отправляете на обработку. Это будет правильно.
Данные которые идут на обработку не должны быть отображены, поэтому нельзя вью ссылаться на модель

Добавлено через 1 минуту
Просто надо четко для себя различать - эти отображаются, эти обрабатываются.

Добавлено через 2 минуты
Вместо класса можно использовать стуктуру. Тогда данные отправленные во VM - будут копиями, которые и будут отображаться. Так можно повысить скорость работы.

@proa33 · 16.02.2019, 13:50

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

Это же классы Модели, а не VM. Если их объявить в VM, то Модель не сможет ими пользоваться.

тут нужна конкретика.
зачем объявлять во view классы модели? view это только отображения через рефлексию.
какая разница какой класс. Binding работает с простыми именами типа String, по которым ищется в ссылке на объект фунция Getter. Какой там класс стоит за ним - до лампочки.

@Элд Хасп · 16.02.2019, 23:42 **[ТС]**

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

тут нужна конкретика.

Решение состоит из проектов View->ViewModelLibrary->ModelLibrary
Класс PersonVM расположенный в ViewModelLibrary

C#
1
2
3
4
5
6
7
8
9
10
11
    public class PersonVM : OnPropertyChangedClass
    {
        private string _firstName;
        private string _secondName;
        private DateTime _birthday;
 
        public string FirstName { get => _firstName; set { _firstName = value; OnPropertyChanged(); } }
        public string SecondName { get => _secondName; set { _secondName = value; OnPropertyChanged(); } }
        public DateTime Birthday { get => _birthday; set { _birthday = value; OnPropertyChanged(); } }
 
    }

Класс ViewModelDD расположенный тоже в ViewModelLibrary (для упрощения заполнил его при инициализации - без Модели)

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
    public class ViewModelDD : OnPropertyChangedClass
    {
        private List<PersonVM> _listPersons;
 
        public List<PersonVM> ListPersons { get => _listPersons; set { _listPersons = value; OnPropertyChanged(); } }
 
        public ViewModelDD()
        {
            ListPersons = new List<PersonVM>()
            {
                new PersonVM()
                { FirstName= "Пётр" ,SecondName="Александрович" ,Birthday= DateTime.Parse("01.01.2000") },
                new PersonVM()
                { FirstName= "Маша" ,SecondName="Ивановна" ,Birthday= DateTime.Parse("02.02.2002")},
                new PersonVM()
                { FirstName = "Питер", SecondName = "Пэн", Birthday = DateTime.Parse("03.03.2003") }
            };
        }
    }

View - MainWindow.xaml

XML
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
<Window x:Class="ClassModelInView.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:vmlib="clr-namespace:ViewModelLibrary;assembly=ViewModelLibrary"
        mc:Ignorable="d"
        Title="MainWindow" Height="150" Width="350">
    <Window.Resources>
        <DataTemplate DataType="{x:Type vmlib:PersonVM}" x:Key="PersonForList">
            <TextBlock>
                <Run Text="{Binding FirstName}"/>
                <Run Text="{Binding SecondName}"/>
            </TextBlock>
        </DataTemplate>
    </Window.Resources>
    <Window.DataContext>
        <vmlib:ViewModelDD/>
    </Window.DataContext>
    <Grid Margin="10">
        <Grid.ColumnDefinitions>
            <ColumnDefinition/>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>
        <ListBox x:Name="listBox" ItemsSource="{Binding ListPersons}" ItemTemplate="{StaticResource PersonForList}" SelectedIndex="1"/>
        <StackPanel Grid.Column="1" DataContext="{Binding SelectedItem, ElementName=listBox}">
            <TextBlock>
                <Run Text="Имя: "/>
                <Run Text="{Binding FirstName}"/>
            </TextBlock>
            <TextBlock>
                <Run Text="Отчество: "/>
                <Run Text="{Binding SecondName}"/>
            </TextBlock>
            <TextBlock>
                <Run Text="Дата рождения: "/>
                <Run Text="{Binding Birthday, StringFormat=\{0:d\}}"/>
            </TextBlock>
        </StackPanel>
    </Grid>
</Window>

Работает всё без проблем.

Теперь сделаем класс PersonM в ModelLibrary. Просто пустой класс - для примера

C#
1
2
3
4
5
6
namespace ModelLibrary
{
    public class PersonM : OnPropertyChangedClass
    {
    }
}

И класс PersonVM будем наследовать от него - больше ни каких изменений

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
namespace ViewModelLibrary
{
    public class PersonVM : PersonM
    {
        private string _firstName;
        private string _secondName;
        private DateTime _birthday;
 
        public string FirstName { get => _firstName; set { _firstName = value; OnPropertyChanged(); } }
        public string SecondName { get => _secondName; set { _secondName = value; OnPropertyChanged(); } }
        public DateTime Birthday { get => _birthday; set { _birthday = value; OnPropertyChanged(); } }
 
    }
}

Без указания в View ссылки на проект ModelLibrary - решение даже собрать не получится.

Вот вопрос в том, что Модель составляется для работы с данными. В ней есть классы предназначенные для этой работы. В частном случае - это множества классов для разбора ответа от Сервера.
Так как в конечном итоге эти данные для отображения поступают в View (конечно через посредство VM), то как View передать информацию об этих классах?
Если не делать прямой ссылки на библиотеку содержащую эти классы, то в VM надо делать дубликаты этих классов. Даже наследование не поможет - нужны именно дубликаты.
Если дать такую ссылку, то получается связь между View и Model, что нарушает "чистоту" MVVM.

@proa33 · 17.02.2019, 02:22

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

И класс PersonVM будем наследовать от него

и тем самым создали зависимость.
И вы удивляетесь почему ваша View просит предоставить ей класс из Model?
Потому что ей надо "вытащить" все базовые свойства родительского класса(PersonM),
когда она создает DataTemplate, по вашему требованию в этом коде:

XML
1
<DataTemplate DataType="{x:Type vmlib:PersonVM}" x:Key="PersonForList">

Сами создали жесткую ссылку, и думаете, что View будет "лепить" DataTemplate из воздуха?
Решение проблемы:
уберите DataType, потому что он требует прямого доступа ко всей иерархии класса.
и не создавайте жестких ссылок. Без них все работает.
В событии Loaded:

C#
1
DataContext = new VMLibrary.ViewModelDD ();

@Элд Хасп · 17.02.2019, 09:42 **[ТС]**

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

И вы удивляетесь почему ваша View просит предоставить ей класс из Model?

Я не удивляюсь, а интересуюсь наиболее подходящим решением для этого.

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

уберите DataType, потому что он требует прямого доступа ко всей иерархии класса.

Если убирать шаблоны данных Xaml будет излишне перегружен. Отображением данных класса, должны заниматься именно шаблоны данных, для этого они и существуют.
Убрав их придётся делать шаблоны элементов, а это всё таки несколько иное. Шаблон элементов требует прописывание всего визуального поведения. Вот для примера заменив шаблон данных на такой шаблон элемента

XML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
            <ListBox.ItemContainerStyle>
                <Style TargetType="ListBoxItem">
                    <Setter Property="Template">
                        <Setter.Value>
                            <ControlTemplate>
                                <TextBlock>
                                    <Run Text="{Binding FirstName}"/>
                                    <Run Text="{Binding SecondName}"/>
                                </TextBlock>
                            </ControlTemplate>
                        </Setter.Value>
                    </Setter>
                </Style>
            </ListBox.ItemContainerStyle>

Мы получили, во-первых, бОльший код и ,во-вторых, отсутствие выделения цветом выделенного Item. Придётся прописывать полностью весь шаблон. С установкой кистей.
И полностью элемент придётся прописывать так

XML
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
        <ListBox x:Name="listBox" ItemsSource="{Binding ListPersons}" SelectedIndex="1">
            <ListBox.Resources>
                <Style x:Key="FocusVisual">
                    <Setter Property="Control.Template">
                        <Setter.Value>
                            <ControlTemplate>
                                <Rectangle Margin="2" SnapsToDevicePixels="true" Stroke="{DynamicResource {x:Static SystemColors.ControlTextBrushKey}}" StrokeThickness="1" StrokeDashArray="1 2"/>
                            </ControlTemplate>
                        </Setter.Value>
                    </Setter>
                </Style>
                <SolidColorBrush x:Key="Item.MouseOver.Background" Color="#1F26A0DA"/>
                <SolidColorBrush x:Key="Item.MouseOver.Border" Color="#a826A0Da"/>
                <SolidColorBrush x:Key="Item.SelectedInactive.Background" Color="#3DDADADA"/>
                <SolidColorBrush x:Key="Item.SelectedInactive.Border" Color="#FFDADADA"/>
                <SolidColorBrush x:Key="Item.SelectedActive.Background" Color="#3D26A0DA"/>
                <SolidColorBrush x:Key="Item.SelectedActive.Border" Color="#FF26A0DA"/>
            </ListBox.Resources>
            <ListBox.ItemContainerStyle>
                <Style TargetType="ListBoxItem">
                    <Setter Property="Template">
                        <Setter.Value>
                            <ControlTemplate TargetType="{x:Type ListBoxItem}">
                                <Border x:Name="Bd" BorderBrush="{TemplateBinding BorderBrush}" BorderThickness="{TemplateBinding BorderThickness}" Background="{TemplateBinding Background}" Padding="{TemplateBinding Padding}" SnapsToDevicePixels="true">
                                    <TextBlock>
                                    <Run Text="{Binding FirstName}"/>
                                    <Run Text="{Binding SecondName}"/>
                                    </TextBlock>
                                </Border>
                                <ControlTemplate.Triggers>
                                    <MultiTrigger>
                                        <MultiTrigger.Conditions>
                                            <Condition Property="IsMouseOver" Value="True"/>
                                        </MultiTrigger.Conditions>
                                        <Setter Property="Background" TargetName="Bd" Value="{StaticResource Item.MouseOver.Background}"/>
                                        <Setter Property="BorderBrush" TargetName="Bd" Value="{StaticResource Item.MouseOver.Border}"/>
                                    </MultiTrigger>
                                    <MultiTrigger>
                                        <MultiTrigger.Conditions>
                                            <Condition Property="Selector.IsSelectionActive" Value="False"/>
                                            <Condition Property="IsSelected" Value="True"/>
                                        </MultiTrigger.Conditions>
                                        <Setter Property="Background" TargetName="Bd" Value="{StaticResource Item.SelectedInactive.Background}"/>
                                        <Setter Property="BorderBrush" TargetName="Bd" Value="{StaticResource Item.SelectedInactive.Border}"/>
                                    </MultiTrigger>
                                    <MultiTrigger>
                                        <MultiTrigger.Conditions>
                                            <Condition Property="Selector.IsSelectionActive" Value="True"/>
                                            <Condition Property="IsSelected" Value="True"/>
                                        </MultiTrigger.Conditions>
                                        <Setter Property="Background" TargetName="Bd" Value="{StaticResource Item.SelectedActive.Background}"/>
                                        <Setter Property="BorderBrush" TargetName="Bd" Value="{StaticResource Item.SelectedActive.Border}"/>
                                    </MultiTrigger>
                                    <Trigger Property="IsEnabled" Value="False">
                                        <Setter Property="TextElement.Foreground" TargetName="Bd" Value="{DynamicResource {x:Static SystemColors.GrayTextBrushKey}}"/>
                                    </Trigger>
                                </ControlTemplate.Triggers>
                            </ControlTemplate>
                        </Setter.Value>
                    </Setter>
                </Style>
            </ListBox.ItemContainerStyle>
        </ListBox>

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

@proa33 · 17.02.2019, 11:07

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

Если убирать шаблоны данных Xaml будет излишне перегружен. Отображением данных класса, должны заниматься именно шаблоны данных, для этого они и существуют.

а где я писал, что надо "убирать шаблоны данных"???
я написал, что надо убрать DataType из определения в шаблонах данных,
если объяснять на пальцах, то надо вместо

XML
1
<DataTemplate DataType="{x:Type vmlib:PersonVM}" x:Key="PersonForList">

надо писать

XML
1
<DataTemplate x:Key="PersonForList">

@Элд Хасп · 17.02.2019, 13:48 **[ТС]**

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

я написал, что надо убрать DataType из определения в шаблонах данных,

Ок!
Да, моя невнимательность! Не так понял Вас.

Это решает часть проблем. Но ещё часть остаётся.
Главное приходится создавать все привязки в "слепую", так как в конструкторе View эти свойства не видны. И отладить View можно будет только после создания приложения целиком. Но по концепции MVVM, View создаётся ещё до создания ViewModel и отлаживаться она должна на ViewModelDD, которая заполняется в Xaml.
Даже, если не использовать DataType , то отладить View не получится.

@proa33 · 17.02.2019, 14:43

так вписывайте DataType где надо и отлаживайте, но с тем ограничением, что класс к которому она обращается, не должен уходить корнями в сборку, которую вы не хотите включать.
Вот и все.

@Элд Хасп · 17.02.2019, 15:00 **[ТС]**

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

так вписывайте DataType где надо и отлаживайте, но с тем ограничением, что класс к которому она обращается, не должен уходить корнями в сборку, которую вы не хотите включать.
Вот и все.

Я понимаю, что "вот и всё".

Но суть-то темы и моего интереса и была в том, как быть когда в View нужна информация о классах из Model ? Ну, не обойтись без этого ! Конечно, не вообще, а в конкретном случае.

Вот у меня в начале темы и были три варианта как поступить в таком случае. Может есть ещё какие-то подходы в таком случае. За это и интересуюсь.

@proa33 · 17.02.2019, 15:40

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

Но View не имеет информации о классе Person и не может отобразить его свойства.

сама WPF дает вам ответ - нет нельзя отобразить информацию о Person не имея ссылки на сборку, где определен этот класс.
Какие тут могут быть "варианты"?
Я предположил, что неясен вопрос как биндить свойства не имея информации о классе.
Я ответил, что это не нужно и свойства биндиться по их именам и неважно в каком классе они находятся. То есть два разных класса

C#
1
2
3
4
5
6
7
8
9
10
11
class One
{
public int year{get;set;}
public string name {get;set;}
}
 
class Two
{
public int year{get;set;}
public string name {get;set;}
}

будут отображаться в одной и той же View одинаково.

@Storm23 · 17.02.2019, 16:05

Элд Хасп,
Во-первых. Насчет того может ли View знать о Model или нет.
Ответ - может. Предназначение View - отображать модель. Она естественным образом зависит от модели. При изменении модели, View полюбому будет меняться.

Во-вторых. Несмотря на то, что view может знать о модели, нужно уменьшать число связей между слоями приложения. Кроме того, у View и Model уже есть посредник в виде ViewModel. Если View будет обращаться то к модели, то к ViewModel - будет действительно нехорошо.

В-треьтих. Как же решается эта проблема? Есть два подхода.
Первый - так называемый "плоский вариант". Этот вариант подразумевает то, что View привязывается только к "простым" типам (string, int, float и т.д.) из ViewModel.
Этот вариант подразумевает, что ViewModel будет дублировать все свойства объектов модели.

Второй подход - это использование DTO объектов для передачи информации между View, ModelView и Model (особенно если Model - удаленная, находится на сервере, этот как раз ваш вариант, как я понял).
DTO объекты не содержат логики и не являются частью модели. О DTO объектах могут знать все слои приложения. Эти объекты выносятся в отдельную dll которая используется как моделью, так и в View и ViewModel.
При этом цепочка данных идет таким образом:
Модель - вещь в себе, работает со своими доменными объектами как хочет, о внешнем коде ничего не знает.
По запросу извне - модель отправляет данные в виде DTO. Сами доменные объекты не отправляются. Обновление данных в модели также происходит через отправку им DTO.
Далее, ViewModel принимает DTO от модели и расшаривает DTO как свое свойство.
View - биндится к DTO, расшаренному в ViewModel.
Если пользователь меняет данные, то ViewModel отправляет DTO обратно в модель.
Для нотификации о том, что свойства DTO поменялись - можно либо реализовать INotifyPropertyChanged у DTO, либо ViewModel может сравнить DTO полученный от сервера и текущий DTO, и если они различаются - отправлять измененный DTO обратно в модель.

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	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 . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

@Элд Хасп Модератор 16115 / 11236 / 2887 Регистрация: 21.04.2018 Сообщений: 33,037 Записей в блоге: 2

	Классы Model в View 14.02.2019, 23:08. Показов 5073. Ответов 24 Метки mvvm, wpf (Все метки) Такой концептуальный вопрос. Есть, допустим, класс Person (ID, Name, Family) в библиотеке Model (ModelLib). Модель построена, всё отлажено. Выдаёт данные, в том числе типа Person. Приступаем к созданию View. Но View не имеет информации о классе Person и не может отобразить его свойства. Можно дать View ссылку на ModelLib, но корректно ли это в рамках MVVM? Можно сделать в рамках ViewModelDD класс, допустим PersonVM, собирающий нужные свойства из класса Person. Но тогда придётся каждый экземпляр Person оборачивать экземпляром PersonVM. Можно сделать общую для всех библиотеку и туда запихнуть Person. Но по сути это вариация первого подхода. Что посоветуете? Как более правильно реализовать в рамках MVVM ? 0

@Рядовой 1524 / 914 / 329 Регистрация: 17.05.2015 Сообщений: 3,438
	15.02.2019, 08:05
	Элд Хасп, а что отображать требуется? один экземпляр класса или массив? 0

@novikov.ea 1857 / 1363 / 429 Регистрация: 10.06.2011 Сообщений: 2,136
	15.02.2019, 09:04
	Вариант 1. Имеются ли какие-то аргументы, чтобы так нельзя было делать? В общем случае, если нужно просто отобразить данные во вью, то следует использовать класс модели. Если отображение имеет свою дополнительную логику: нужно отобразить значение, вычисленное из других свойств или объектов, обработать пользовательский ввод, иметь на уровне класса команду, то тогда следует создать для класса модели соответствующую ей вью-модель. 0

@skilllab 296 / 236 / 58 Регистрация: 03.02.2011 Сообщений: 2,045 Записей в блоге: 1
	15.02.2019, 10:54
	В случае прямого биндинга модели ко View нужно всегда помнить что сделал именно так. Т.е. в случае когда ТОЧНО знаешь что расширенных действий не понадобится (как указал novikov.ea). В противном случае XAML в последствии может жутко разрастись, потом накатится VM, и, в какой либо момент времени, настанет случай кода View будет ссылаться и на VM и на модель. Что приведёт к пипец каким нервам))) и говнокоду. Добавлено через 2 минуты Имхуется, что прямой биндинг прям вот необходим в случае простого отображения уже вычисленных данных, информационных сообщений, содержащих значения из модели, окон ошибок ввода или проверок. 0

@Элд Хасп Модератор 16115 / 11236 / 2887 Регистрация: 21.04.2018 Сообщений: 33,037 Записей в блоге: 2
	15.02.2019, 14:45 [ТС]
	Рядовой, вот такой пример. Класс Person (ID, Name, Family). Ответ от сервера приходит в формате массива, где ID, Name и Family - это элементы массива. Элементы массива в View я показать не могу. Нужны свойства. Делаю в VM наследника от Person в котором свойства берут свои значения от элементов массива базового класса. Если View меняет значения свойств, то я без проблем отправляю наследника в Model он сам там дефолтно приводится к базовому классу и сохраняется. Но! Базовый класс объявлен в Модели и View требует ссылку на Модель. Поэтому и возникла вышеуказанная схема, где классы Модели находятся в отдельной библиотеке и View получает ссылку на эту библиотеку. Но корректно ли это? Может я слишком узко смотрю и есть какое-то другое более типовое решение? 0

@proa33 1595 / 600 / 185 Регистрация: 05.12.2015 Сообщений: 970
	17.02.2019, 14:43
	так вписывайте DataType где надо и отлаживайте, но с тем ограничением, что класс к которому она обращается, не должен уходить корнями в сборку, которую вы не хотите включать. Вот и все. 0

@Storm23 10425 / 5155 / 1825 Регистрация: 11.01.2015 Сообщений: 6,226 Записей в блоге: 34
	17.02.2019, 16:05
	Сообщение было отмечено Элд Хасп как решение Решение Элд Хасп, Во-первых. Насчет того может ли View знать о Model или нет. Ответ - может. Предназначение View - отображать модель. Она естественным образом зависит от модели. При изменении модели, View полюбому будет меняться. Во-вторых. Несмотря на то, что view может знать о модели, нужно уменьшать число связей между слоями приложения. Кроме того, у View и Model уже есть посредник в виде ViewModel. Если View будет обращаться то к модели, то к ViewModel - будет действительно нехорошо. В-треьтих. Как же решается эта проблема? Есть два подхода. Первый - так называемый "плоский вариант". Этот вариант подразумевает то, что View привязывается только к "простым" типам (string, int, float и т.д.) из ViewModel. Этот вариант подразумевает, что ViewModel будет дублировать все свойства объектов модели. Второй подход - это использование DTO объектов для передачи информации между View, ModelView и Model (особенно если Model - удаленная, находится на сервере, этот как раз ваш вариант, как я понял). DTO объекты не содержат логики и не являются частью модели. О DTO объектах могут знать все слои приложения. Эти объекты выносятся в отдельную dll которая используется как моделью, так и в View и ViewModel. При этом цепочка данных идет таким образом: Модель - вещь в себе, работает со своими доменными объектами как хочет, о внешнем коде ничего не знает. По запросу извне - модель отправляет данные в виде DTO. Сами доменные объекты не отправляются. Обновление данных в модели также происходит через отправку им DTO. Далее, ViewModel принимает DTO от модели и расшаривает DTO как свое свойство. View - биндится к DTO, расшаренному в ViewModel. Если пользователь меняет данные, то ViewModel отправляет DTO обратно в модель. Для нотификации о том, что свойства DTO поменялись - можно либо реализовать INotifyPropertyChanged у DTO, либо ViewModel может сравнить DTO полученный от сервера и текущий DTO, и если они различаются - отправлять измененный DTO обратно в модель. 1