WPF vs WinForms (для начинающих) [Элд Хасп]

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

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

Тема из цикла Готовые решения, примеры и рекомендации начинающим на WPF [Элд Хасп]

Эту тему решил создать, так как очень часто сталкиваюсь с неверными решениями начинающих которые имеют опыт работы с WinForms. Очень часто этот опыт работы оказывается не то, что ненужным, а даже мешающим нормальному освоению WPF. Так же, как я понял, у подавляющего большинства преподавателей ВУЗов полностью отсутствуют знания в этой области и преподавание происходит, фактически, на уровне ФОРТРАН тридцатилетней давности.

Основные моменты WPF, которые я считаю принципиально отличными от WinForms:

1) Компоновка элементов окна (в Winforms - формы)

Принципиальным отличием является то, что размеры и положение WPF элементов являются нежёсткими как в WinForms. В большинстве случаев эти параметры относительны контейнера в который входят элементы. Поэтому компоновка производится сочетанием различных контейнеров (а их на много больше чем в WinForms) и указанием того как в этих контейнерах надо разместить элементы: растянуть, по центру, сверху и т.д.

К сожалению, конструктор Visual Studio не помогает в освоении компоновки WPF. При вставке элемента (как это делается в конструкторе WinForms) элемент жёстко позиционируется с помощью свойства Margin элемента. Из-за этого начинающие поддаются заблуждению, что так и надо делать. Я сам по началу попал в этот капкан.

Margin - это свойство для задания расстояния между элементами, а не положения элемента!

Из-за этой особенности конструктора WPF, элементы окна не надо создавать перетаскиванием на окно. Их надо прописывать в XAML окна "в ручную". Правильная компоновка элементов делает окно адаптивным. Элементы в нём сами меняют свои размеры и положение в зависимости от размеров окна и окружающих элементов. Всё это является "внутренним" изначально присущим свойством WPF элементов и не требует поддержки в коде C# в CB окна. Конечно, такие способности не являются абсолютными. И создать окно которое одинаково хорошо чувствует себя на 2-х метровом мониторе и на экране смартфона, вряд ли, получится. Для этого существуют решения UWP, но это уже другая тема.

Вот пример простого WPF окна. В примере используется элемент ViewBox - он позволяет "растягивать" даже не растягиваемые элементы, объекты. Очень часто используется для изменения размера шрифта текста.

Попробуйте запустить проект с этим окном и посмотрите как будут меняться элементы в зависимости от размеров окна. Сделать такое в коде C# на WinForms потребует нетривиальных усилий.

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
<Window x:Class="WPFvsWinForms.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:local="clr-namespace:WPFvsWinForms"
        xmlns:sys="clr-namespace:System;assembly=mscorlib"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800">
    <Grid Background="Aqua">
        <Grid.RowDefinitions>
            <RowDefinition/>
            <RowDefinition/>
            <RowDefinition/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition/>
            <ColumnDefinition/>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>
        <Viewbox Grid.ColumnSpan="3" Margin="10" >
               <TextBox Text="Пример TextBox в контейнере ViewBox"/>
        </Viewbox>
        <Button Grid.Row="1" Grid.Column="1" Margin="20">Центральная кнопка</Button>
        <ListBox Grid.Row="1" Grid.RowSpan="2" Margin="15">
            <ListBox.ItemsSource>
                <sys:String>Набор строк</sys:String>
            </ListBox.ItemsSource>
        </ListBox>
        <Button Grid.Row="1" Grid.Column="2" Margin="20">Правая кнопка</Button>
        <StackPanel Orientation="Horizontal" Grid.Row="2" Grid.Column="1" Grid.ColumnSpan="2">
            <TextBlock VerticalAlignment="Center" Margin="5">Это аналог Label в WinForms</TextBlock>
            <Button Grid.Row="1" Grid.Column="2" Margin="20">Кнопка в StackPanel</Button>
            <Border Background="LightGreen" Padding="10">
                <TextBlock VerticalAlignment="Center">Это TextBox в Border</TextBlock>
            </Border>
        </StackPanel>
    </Grid>
</Window>

WPF vs WinForms (для начинающих) [Элд Хасп]

2) Внешний вид элементов

В WinForms внешний вид элементов поменять можно только из CB окна и в относительно небольших рамках.

Для изменения внешнего вида элементов в WPF используется XAML. Это, фактически, самостоятельный язык для программирования элементов WPF. Возможности его (по сравнению с WinForms) просто огромны. Изменять можно почти всё.

Посмотрите пример с ListBox с разной 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
<Window x:Class="WPFvsWinForms.ListBoxes"
        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:local="clr-namespace:WPFvsWinForms"
        xmlns:sys="clr-namespace:System;assembly=mscorlib"
        mc:Ignorable="d"
        Title="ListBoxes" Height="450" Width="800">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition/>
            <RowDefinition/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition/>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>
        <Grid.Resources>
            <sys:String x:Key="ListSource">ABCDEFGHIJKLMNOPQRSTUVWXYZ</sys:String>
        </Grid.Resources>
        <ListBox  ItemsSource="{StaticResource ListSource}"/>
        <ListBox  Grid.Column="1" ItemsSource="{StaticResource ListSource}" ScrollViewer.HorizontalScrollBarVisibility="Disabled" FontSize="48">
            <ListBox.ItemsPanel>
                <ItemsPanelTemplate>
                    <WrapPanel />
                </ItemsPanelTemplate>
            </ListBox.ItemsPanel>
        </ListBox>
        <ListBox Grid.Row="1" Grid.ColumnSpan="2" ItemsSource="{StaticResource ListSource}" FontSize="36">
            <ListBox.ItemsPanel>
                <ItemsPanelTemplate>
                    <StackPanel Orientation="Horizontal"/>
                </ItemsPanelTemplate>
            </ListBox.ItemsPanel>
        </ListBox>
    </Grid>
</Window>

Поэтому выбирать элементы WPF надо не по внешнему виду, а по логике поведения.

Для ListBox - это вывод списка элементов (в любой визуальной форме) и возможность выбора элементов из этого списка.

И для нормальной работы с WPF надо изучать XAML: стили, шаблоны, словари и т.д. Без этого невозможно сделать нормальное WPF приложение.

Для почти всех элементов можно посмотреть дефолтный шаблон и разобравшись в в его работе, можно понять и как его надо изменить. Дефолтный шаблон можно получить правым кликом по элементу в окне конструкторе и выбрав "Правка шаблона" или "Правка дополнительных шаблонов": Получение шаблона элемента [WPF, Элд Хасп].

3) Привязки элементов

В WinForms для обновления значений элементов надо изменять эти значения из ViewModel, а часто ещё и вызывать принудительно перерисовку элементов. Поэтому Code Behind (CB) для WinForms забит именами элементов, вызовами их свойств и методов.

И смысл паттерна MVVM из-за этого теряется. Да, его в WinForms полноценно реализовать и невозможно.

В WPF введён мощный инструмент привязок для свойств элементов. Хотя сами привязки появились ещё на Формах, но в Формах требовалось много "ручного" кода для их внедрения. А в WPF Привязки уже интегрированы в платформу UI элементов, их очень легко задавать в XAML. Элементы сами запрашивают значения из привязанных свойств других элементов, из свойств VM и других источников. VM только должна известить через интерфейсы INotifyPropertyChanged или INotifyCollectionChanged об изменении своих свойств и коллекций или это должны быть свойства зависимостей. А какие элементы и когда будут считывать значения свойств - VM не знает. Поэтому в WPF должно быть полное разделение VM и View. VM - не может обращаться к визуальным элементам, она, вообще, про них ничего знать не должна.

В самом же окне надо всё делать через привязки, как к свойствам VM так и к свойствам элементов. Составление привязок, тоже порой не просто. Особенно для списочных элементов, многоуровненных элементов. Но их надо изучать! И делать WPF решения надо только используя привязки. Ни в коем случае не надо подаваться привычкам от WinForms создание элементов в коде C#, обновление значений элементов из кода C#.

Ещё трудная тема для WPF - это команды.

Обработка изменений в WinForms делается через события. В WPF такое тоже возможно, но не желательно. Для многих случаев вместо событий можно использовать сеттеры привязанных свойств в VM.

Но для кнопок, меню надо использовать команды. К сожалению, MS как-то не до конца проработала эту часть WPF. Для работы с командами не хватает дефолтных возможностей WPF. Приходится создавать свои классы для этого. Здесь я не буду углубляться в эту тему. Но обращу внимание на два момента.

Команда это View компонента. Она может всплывать по визуальному дереву WPF от элемента к элементу. На каком-то уровне её надо перехватить и привязать к свойству VM типа ICommand.

4) Code-Behind окна

В WinForms CB это необходимая и неотъемлемая часть приложения. Без CB очень трудно что-то сделать.
В WPF ситуация обратная.

Свойства элементов обновляются через привязки указанные в XAML. Внешний вид элементов изменяется в XAML. События обрабатываются через команды, свойства VM, анимацию (здесь я эту тему не затрагиваю). Поэтому в идеале CB WPF окна должен быть пустой! Он содержит только строку в конструкторе с вызовом инициализации элементов и может содержать создание связи с VM. Всё больше ничего не должно быть.

Всегда ли надо строго следовать этому? Ну, идеал - это идеал. Конечно, иногда вместо создания одноразового Custom Control, проще вписать небольшой код в CB. Но в процессе обучения - это следование идеалу должно быть строгим. Для развития необходимых навыков программирования WPF решений. Надо знать и уметь делать правильно! Со временем, с появлением необходимого багажа знаний следование этому правилу может быть не таким строгим.

Архив проекта приложен

@titan4ik · 10.08.2019, 20:10

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

"Идеал" - для получения начинающему необходимого опыта.

Я сам учусь как бы (в вялотекущем режиме) то тому, то этому. И пробежав ранее тему WPF поверхностно и сейчас, планируя обратиться к ней снова, могу сказать, что для меня, как для "обучающегося", "идеал" - это прежде всего получить для себя ясный ответ на два основополагающих вопроса:
1. Само корректное определение MVVM и конкретное понимание того, как распределять код (по его содержанию) между Model (моделью), ViewModel (представлением модели) и View (представлением). Эта тема актуализировалась после того, как увидел на метаните, что модель можно создавать и без реализации интерфейса INotifyPropertyChanged (мне это понравилось).
2. Понимание в каких случаях и в каких местах (и по каким критериям) в рамках приложения WPF, создаваемого по паттерну MVVM, рационально отступать от этого паттерна и использовать CB (напр обработчики событий нажатия на кнопки).

а потом уже двигаться далее. Попозже мейби сделаю эти две темы. Именно с них, имхо, и нужно в идеале начинать всем начинающим.

@Элд Хасп · 10.08.2019, 20:49 **[ТС]**

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

для меня, как для "обучающегося", "идеал" - это прежде всего получить для себя ясный ответ

Ещё раз уточняю - эта тема не за то как надо реализовывать WPF+MVVM. А за отличия между WF и WPF. И как быстрее отучиться от негативного опыта реализации решений на WF.

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

модель можно создавать и без реализации интерфейса INotifyPropertyChanged

INPC - удобен из-за его "простоты". Но он годится только для очень простых задач.
Поэтому INPCC в Модели - это скорее учебная реализация чем решение реальной задачи.
В некоторых случаях возможна реализация Модели, вообще, без событий.

Что вы увидели Метаните - не знаю. Вы не дали ссылки. Поэтому обсуждать неизвестно что - не могу.

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

2. Понимание в каких случаях и в каких местах (и по каким критериям) в рамках приложения WPF, создаваемого по паттерну MVVM, рационально отступать от этого паттерна и использовать CB (напр обработчики событий нажатия на кнопки).

Использование CB не противоречит MVVM. А вот обработка данных в View - противоречит.
То есть даже если нужно создать обработчик события в CB, то в нём можно обращаться только к элементам View или к методам VM. Но ни как нельзя к данным.

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

Понимание в каких случаях и в каких местах (и по каким критериям) в рамках приложения WPF, создаваемого по паттерну MVVM, рационально отступать от этого паттерна

В реальных решениях WPF - никогда.
В каком-нибудь маленьком, созданном для теста, проверки? поиска решения - без проблем.

@titan4ik · 10.08.2019, 21:38

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

Вы не дали ссылки. Поэтому обсуждать неизвестно что - не могу.

https://metanit.com/sharp/wpf/22.2.php
Последний раздел на странице - "Определение модели".
Это просто к сведению. Раз тема не про это, то нет смысла тут это обсуждать. К тому же нужно бы проблему сформулировать, а я не готов ещё)

Добавлено через 6 минут
P.S. Замечу только, что представляется, что и по данной части есть элемент терминологической путаницы в литературе и обсуждениях - с понятием "модель" в программировании. Наверное это связано с тем, что все эти термины в контексте программирования пришли из англ языка из переводных книг. Есть ещё такой дурацкий термин "бизнес-логика").

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

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

В реальных решениях WPF - никогда.

на метаните мягче формулировка:

Для взаимодействия пользователя и приложения в MVVM используются команды. Это не значит, что вовсе не можем использовать события и событийную модель, однако везде, где возможно, вместо событий следует использовать команды.

@Элд Хасп · 10.08.2019, 21:47 **[ТС]**

titan4ik, я пытался читать несколько книг.... Для меня толку не было.
В основном использовал и использую METANIT, professorweb, docs.microsoft.
И самое важное делаю очень много разнообразных решений. Именно это помогло понять и освоить C#+WPF+MVVM.
По началу делал решения WPF аналогично WF решениям с активным использованием CB. Потихоньку, по мере понимания, стал добавлять разделение кода на M+V+VM, использовать привязки в View. И в какой-то момент пришло понимание.
После этого оказалось, что нормально сделанное решение WPF+MVVM создаётся гораздо проще и быстрее чем WPF+CB.
Когда начало приходить понимание, то для быстрейшего переучивания я создавал решения с полностью пустым CB. Мне это сильно помогло быстрее освоить WPF+MVVM.

@Элд Хасп · 10.08.2019, 21:53 **[ТС]**

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

на метаните мягче формулировка:

Я ещё раз пишу.
Использование событий не противоречит MVVM!
Да, команды в MVVM проще использовать, так как они привязываются сразу к методам VM.
Но команды не всегда возможно использовать. И если приходится создавать обработчик события - создавайте!

Противоречит MVVM - ОБРАБОТКА ДАННЫХ в View. И без разницы где это обработка происходит в событии или команде (для команды тоже можно задать код в CB).

Поэтому ответ остаётся такой же В реальных решениях WPF - никогда. Но этот ответ нисколько не противоречит приведённой вами цитате из METANIT. Это цитат просто о другом!

@titan4ik · 10.08.2019, 21:54

Это всё понятно. И ещё раз - здорово, что Вы свой личный опыт тут излагаете в порядке его формирования. Это очень поучительно.
Однако, и WPF уже существует много лет и паттерн MVVM - и логично было бы предположить, что всё в этом должно быть отработано и выверено. И формулировки и критерии выбора подходов и конкретные реализации паттерна вылизаны должны быть до совершенства и четко сформулированы. А я пока (может я заблуждаюсь) вижу путаницу повсеместно даже в основополагающих определениях. Удивительно)

@Элд Хасп · 10.08.2019, 22:07 **[ТС]**

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

WPF уже существует много лет и паттерн MVVM

MVVM возник раньше.
И когда MS решили создавать WPF, то они его "заточили" специально под MVVM. Именно поэтому, если WF решение можно реализовать как в CB формы, так и в любом паттерне MVC, MVP, MVVM и т.д., то реализация WPF решения вне MVVM - это создание сложностей самому себе. WPF без MVVM - это "микроскоп для забивания гвоздей".

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

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

А я пока (может я заблуждаюсь) вижу путаницу повсеместно даже в основополагающих определениях

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

@proa33 · 11.08.2019, 19:57

вот статья. не тему, но тоже о коцепциях

https://habr.com/ru/company/mobileup/blog/335382/

@titan4ik · 11.08.2019, 21:38

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

вот статья. не тему, но тоже о коцепциях

того же автора в тему: "Как перестать использовать MVVM"

https://habr.com/ru/company/mobileup/blog/312548/

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

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

вот статья

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

того же автора в тему:

proa33, titan4ik, может я чё-то не догоняю...
А причём здесь C#+WPF+MVVM?
Тем более в теме WF vs WPF?

@titan4ik · 11.08.2019, 23:15

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

proa33, titan4ik, может я чё-то не догоняю...
А причём здесь C#+WPF+MVVM?
Тем более в теме WF vs WPF?

Отвечаю.
Ваша тема "WPF vs WinForms (для начинающих)", насколько я понял, по русски могла бы звучать так - "Проблемы изучения WPF после WinForms и некоторые методы их преодоления".
WPF заточено на применение паттерна MVVM. Мы говорм WPF, подразумеваем паттерн MVVM, мы говорим MVVM, подразумеваем, что без него WPF - это чемодан без ручки (это не моё мнение, это как бы общее место). Поэтому начинающему важно подходить к изучению осознанно, с пониманием того, что он идёт по верному пути, что паттерн MVVM - это то, что нужно. Паттерн - он и в Африке паттерн. И поэтому компетентное мнение чела, получившего опыт работы с этим паттерном на другом языке, тоже может быть интересно начинающему (с опытом WF). Я и там обнаружил кое-что, что мэйби использую при создании новой темы "по определению паттерна MVVM" (если доживу до этого светлого момента: у меня крепнет ощущение, что определение паттерна говорит об одном, а практика паттерна часто - о другом).
Как написал Дейт в эпиграфе к своей книге:

К сожалению, разрыв между теорией и практикой в теории не настолько широк, как на практике.

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

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

это не моё мнение, это как бы общее место

Полностью согласен.
WPF изначально создавался как способ реализации VIEW в патnерене MVVM.

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

Поэтому начинающему важно подходить к изучению осознанно, с пониманием того, что он идёт по верному пути, что паттерн MVVM - это то, что нужно. Паттерн - он и в Африке паттерн. И поэтому компетентное мнение чела, получившего опыт работы с этим паттерном на другом языке, тоже может быть интересно начинающему (с опытом WF).

А вот это не пойму... или понимаю по иному.
WPF вне C# и Net, по большому счёту, лишён смысла.
WF используют вне C# (часто на VB), но вне Net он тоже бессмыслен.

Поэтому, на мой взгляд, тема даже не о том, что лучше WF или WPF. А о том какие трудности и нюансы есть при переходе с одной платформы на другую, но НЕ МЕНЯЯ ЯЗЫК и FrameWork.

Если же мы ведём дискуссию, что лучше для Андроид - то однозначно это будет не C#+WPF или C#+WF. Но такая дискуссия, совершенно, не относится к данной теме.

@titan4ik · 11.08.2019, 23:58

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

Но такая дискуссия, совершенно, не относится к данной теме.

Это косяк. Сорри. Если у Вас такие права есть - удалите мои сообщения начиная с №29, чтобы тему не засорять. Так лучше будет.

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

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

Если у Вас такие права есть - удалите мои сообщения начиная с №29, чтобы тему не засорять. Так лучше будет.

Да, нет - пусть остаётся.
Я бы даже это вынес в отдельную тему - вопрос сейчас актуальный.
Но вот даже не знаю в какой раздел?
Это раздел C#+WPF и здесь не место. А где место? В каком разделе?

@Leshakk · 06.03.2023, 16:10

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

Из моего опыта помощи очень многим, переучиваться гораздо сложнее чем учиться изначально правильно. Об этом я и написал в самом начале. Опыт работы с WF при переходе на WPF не просто бесполезен, он мешает обучению и является отрицательным фактором.
Это как в анекдоте:
- Научите играть на скрипке!
- За 100 рублей!
- А что так дорого? Я уже немного сам научился!
- Тогда за 200!
- Почему дороже?!
- Ещё 100 за то, чтобы отучить от того чему сами обучились!

Вот прям то, за что голова болела! Спасибо!

Новые блоги и статьи Все статьи Все блоги /
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
	10.08.2019, 21:47 [ТС]
	titan4ik, я пытался читать несколько книг.... Для меня толку не было. В основном использовал и использую METANIT, professorweb, docs.microsoft. И самое важное делаю очень много разнообразных решений. Именно это помогло понять и освоить C#+WPF+MVVM. По началу делал решения WPF аналогично WF решениям с активным использованием CB. Потихоньку, по мере понимания, стал добавлять разделение кода на M+V+VM, использовать привязки в View. И в какой-то момент пришло понимание. После этого оказалось, что нормально сделанное решение WPF+MVVM создаётся гораздо проще и быстрее чем WPF+CB. Когда начало приходить понимание, то для быстрейшего переучивания я создавал решения с полностью пустым CB. Мне это сильно помогло быстрее освоить WPF+MVVM. 1

@titan4ik Заблокирован
	10.08.2019, 21:54
	Это всё понятно. И ещё раз - здорово, что Вы свой личный опыт тут излагаете в порядке его формирования. Это очень поучительно. Однако, и WPF уже существует много лет и паттерн MVVM - и логично было бы предположить, что всё в этом должно быть отработано и выверено. И формулировки и критерии выбора подходов и конкретные реализации паттерна вылизаны должны быть до совершенства и четко сформулированы. А я пока (может я заблуждаюсь) вижу путаницу повсеместно даже в основополагающих определениях. Удивительно) 0

@proa33 1595 / 600 / 185 Регистрация: 05.12.2015 Сообщений: 970
	11.08.2019, 19:57
	вот статья. не тему, но тоже о коцепциях https://habr.com/ru/company/mobileup/blog/335382/ 1