Общие сведения asp.net core mvc

Введение

Современный интерфейс пользователя предполагает событийную модель работы и множество состояний интерфейса. Невозможность задать строгую последовательность взаимодействия пользователя и интерфейса порождает множество сценариев работы программы, соблюсти выполнение которых становится тем сложнее, чем больше реквизитов в форме и запутаннее связи между ними. В общем случае даже связи могут меняться в зависимости от состояния интерфейса. Добавьте к этому еще и ограничения клиент-серверного взаимодействия, и дублирование кода для обхода этих ограничений при необходимости переиспользования объекта интерфейса из других форм или при программном взаимодействии с объектом, минуя интерфейс пользователя.

Программирование интерфейса пользователя — одна из самых сложных алгоритмических задач. История борьбы со сложностью в реализации пользовательского интерфейса уже достаточно продолжительная и придумано не мало решений для её обуздания. Найденные решения описаны в шаблонах проектирования. Остается взять «правильный» шаблон, проверить условия его применимости и найти его реализацию в 1С.

Базовым шаблоном в проектировании интерфейсов является шаблон MVC. В силу особенностей языка 1С найти реализацию этого шаблона было не просто, т.к. все эти шаблоны пришли из мира ООП, а 1С все-таки не поддерживает такую парадигму.

В представленном решении данной статьи описан вариант реализации MVC на 1С через декларативное описание зависимостей. Идея заключается в использовании графа зависимостей реквизитов, на основании которого подсистема сможет вызывать соответствующие обработчики. Сами обработчики можно расположить в общих модулях — это и будет средний слой между интерфейсом и моделью.

MVC

Модель MVC изначально была основана на серверной веб-разработке и постепенно стала пригодной для клиентской веб-разработки, отвечая ее сложности и разнообразию.

MVC — это аббревиатура от Model-View-Controller, которая делит приложение на три части:

• Модель(Используется для обработки данных, связанных с бизнес-логикой приложения, и для чтения данных)

• Посмотреть(Отображаемая страница)

• Контроллер(Соединитель между M и V используется для управления потоком приложения и бизнес-логикой страницы)

Возможности MVC:

Модель MVC характеризуется разделением задач, то есть модель данных в приложении отделена от бизнес-логики и логики представления. В клиентской веб-разработке разделение кода и слабая связь между моделью (M-данные, операционные данные) и представлением (HTML-элемент данных V-display) упрощают разработку, поддержку и тестирование. Клиентское приложение. Все коммуникации односторонние.

1. View отправляет команды контроллеру;

2. После того, как Контроллер завершит бизнес-логику, он требует, чтобы Модель изменила состояние;

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

Процесс MVC:

Есть два типа процессов MVC, которые используются в повседневной разработке.

Один из них — принять инструкции через представление, передать их контроллеру, затем изменить модель или найти базовые данные и, наконец, отобразить изменения в представлении.

Другой — получить инструкции через контроллер и передать их контроллеру:

Преимущества MVC:

• Низкое сцеплениеУровень представления отделен от бизнес-уровня, что позволяет изменять код уровня представления без перекомпиляции кода модели и контроллера.
• Возможность многократного использования
• Низкая стоимость жизненного цикла
• MVC снижает техническое содержание разработки и поддержки пользовательских интерфейсов.
• Высокая ремонтопригодность, Разделение уровня представления и уровня бизнес-логики также упрощает обслуживание и изменение веб-приложений.
• Быстрое развертывание

Недостатки MVC:

• Не подходит для малых и средних приложений, Потратив много времени на применение MVC к не очень большим приложениям, обычно перевешивает выгода.

• Вид и контроллер слишком тесно связаныПредставление и контроллер отделены друг от друга, но являются тесно связанными компонентами.У представления нет контроллера, и его применение очень ограничено, и наоборот, что предотвращает их независимое повторное использование.

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

Приложение MVC:

В начале популярности веб-приложений MVC использовался в серверных приложениях java (struts2) и C # (ASP.NET), а позже в клиентских приложениях появился AngularJS на основе шаблона MVC.

4.3 Presenter — мост между моделью и представлением

В упомянутый выше внутренний код включены P и M. M то же самое, что и в MVC, и относится к логическому коду. P — это мост между моделью и представлением, отвечающий за объединение соответствующей модели и представления вместе.

Для указанного выше IUserAdd соответствующий код докладчика:

public class UserAddPresenter:IPresenter 
{ 
       private readonly IUser _model; 
       private readonly IUserAdd _view; 
       private readonly ApplicationFacade _facade = ApplicationFacade.Instance; //Фасад здесь предназначен для общения между докладчиками, подробности можно увидеть в полном коде.

      //В конструкторе Presenter передайте представление и модель в качестве параметров.

       public UserAddPresenter(IUser model, IUserAdd view) 
       { 
           _model = model; 
           _view = view; 
           WireUpViewEvents(); 
       }

       private void WireUpViewEvents() 
       { 
           _view.UserAddEvent += _view_UserAdd; 
       }

      //Когда запускается событие UserAdd представления, данные в пользовательском интерфейсе получаются, и вызывается логика модели для добавления нового пользователя.
     //Отправить сообщение User_ADDED в систему одновременно (другие части пользовательского интерфейса в системе получают сообщения, такие как DataGrid здесь, после того, как он получит User_ADDED, он обновится)
       private void _view_UserAdd(object sender, EventArgs e) 
       { 
           var user = new User 
                      { 
                          Name = _view.UserName, 
                          Age = Convert.ToInt32(_view.UserAge) 
                      };
           _model.AddItem(user); 
           _facade.SendNotification(ApplicationFacade.USER_ADDED); 
       }
}

Построение на основе лучших частей платформы ASP.NET

Существующая платформа ASP.NET производства Microsoft предлагает зрелый, хорошо проверенный набор компонентов и средств для разработки эффективных и высокопроизводительных веб-приложений. Первое и наиболее очевидное преимущество заключается в том, что поскольку инфраструктура ASP.NET MVC построена на основе платформы .NET, вы вольны писать код на любом языке .NET и при этом иметь доступ к одним и тем же функциям API-интерфейсов, которые определены не только в MVC Framework, но и в обширной библиотеке классов .NET, а также в широком множестве библиотек .NET от независимых разработчиков.

Во-вторых, готовые средства платформы ASP.NET, такие как аутентификация, членство, роли, профили и интернационализация, могут существенно сократить объем кода, который придется писать и поддерживать в любом веб-приложении, и в проекте MVC Framework они столь же эффективны, как в классическом проекте Web Forms. Лежащая в основе платформа ASP.NET предоставляет развитый набор инструментов, на базе которых строятся веб-приложения с помощью MVC Framework.

1С:Предприятие 8.2. Управляемая Форма. Меняем иконку рабочего стола.

Для конфигураций имеющих свой дизайн важно иметь возможность сменить не только картинки разделов для созданных подсистем, но и картинку рабочего стола, но менять ее нет возможности. Сама 1С объясняет это тем что интерфейс любой конфигурации должен быть унифицирован: «Дело не в одной картинке, а в общей стилистике для любых конфигураций

Важно чтобы пользователи привыкали к общему стилю и одинаково воспринимали одинаковые элементы в разных конфигурациях — это ускорит и освоение конфигураций и повседневную работу пользователей с ними.»

Но все же можно попытаться ее сменить.

1 стартмани

Указание представлений в контроллерах

Представления обычно возвращаются из действий в виде ViewResult , который является типом ActionResult . Метод действия может создавать и возвращать объект напрямую, однако обычно так не делается. Поскольку большинство контроллеров наследуют от Controller , вы просто используете вспомогательный метод для возвращения :

Когда это действие возвращается, представление, показанное в последнем разделе, отображается как следующая веб-страница:

Вспомогательный метод имеет несколько перегрузок. Вы можете дополнительно указать:

• Представление, которое нужно вернуть, явным образом:

• Модель, которую нужно передать в представление:

• Представление и модель:

Обнаружение представления

Когда действие возвращает представление, происходит процесс, который называется обнаружением представления. Он служит для определения используемого файла представления на основе имени представления.

Метод () по умолчанию возвращает представление с тем же именем, что и у метода действия, из которого он был вызван. Например, имя метода контроллера используется для поиска файла представления с именем . Сначала среда выполнения ищет в папке представление. Если найти соответствующее представление там не удается, он ищет в папке представление.

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

Вместо имени файла можно предоставить путь к файлу представления. Если используется абсолютный путь, начинающийся с корневого каталога приложения (при необходимости начинается с «/» или «~/»), необходимо указать расширение:

Можно также использовать относительный путь, чтобы указать представления в разных каталогах без расширения. В можно вернуть представление представлений по относительному пути:

Аналогичным образом, можно указать каталог текущего контроллера с помощью префикса «./»:

Частичные представления и компоненты представлений используют похожие (но не одинаковые) механизмы обнаружения.

Можно настроить стандартное соглашение о том, как представления находятся в приложении, с помощью пользовательского IViewLocationExpander .

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

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

MVVM

На AndroidиметьСвязывание данных MVVM имеет преимущества простого тестирования и модульности, а также уменьшает объем кода, который мы должны написать для подключения View + Model.

Давайте посмотрим на различные части MVVM.

ViewModel отвечает за упаковку модели и подготовку наблюдаемых данных, необходимых для View. Он также предоставляет возможность View передавать события модели. Однако ViewModel не зависит от View.

Наша программа разбита в режиме MVVM.

mvvm model role map.png

Давайте подробнее рассмотрим код здесь, начиная с ViewModel.

Проверьте файл xml, чтобы увидеть, как связаны эти переменные и события.

Оценка

Модульное тестирование теперь проще, потому что вы действительно не зависите от View. При тестировании вам нужно только убедиться, что наблюдаемые переменные правильно установлены при изменении модели. Имитировать тестовый View не нужно, потому что есть режим MVP.

MVVM следовать

поддерживать -Поскольку View может быть привязан к переменным и выражениям, нерелевантная логика представления может со временем измениться, эффективно добавляя код в наш XML. Чтобы избежать этого, всегда получайте значения непосредственно из ViewModel вместо того, чтобы пытаться вычислить или получить их в выражении привязки представления. Этот расчет может быть правильно протестирован.

MVVM

Шаблон MVP неплох, но Microsoft придумала шаблон еще лучше — MVVM (Model-View-ViewModel). Этот шаблон очень любят .NET-разработчики, он используется в Silverlight, его реализация есть в AngularJS. MVVM — очень удобный шаблон.

Чем отличается MVVM от MVP?

MVVM позволяет связывать элементы View со свойствами и событиями ViewModel. При этом ViewModel — абстракция представления. В MVVM есть:

• View — содержит поля, соответствующие интерфейсу пользователя.
• ViewModel — содержит такие же поля, но в предметной области.
• Собственно, Model.

Свойства View совпадают со свойствами ViewModel/Model. При этом ViewModel не имеет ссылки на интерфейс представления. Изменение состояния ViewModel автоматически изменяет View, и наоборот. Для этого используется механизм связывания данных. Также характерная черта MVVM — двусторонняя коммуникация с View.

Далее я кратко пройдусь по реализациям MVVM под Android, с которыми сталкивался в работе, и рассмотрю достоинства и недостатки каждой. В свое время я отметил для себя три реализации: RoboBinding, ngAndroid, Bindroid. В конце этого обзора кратко остановлюсь на Android Data Binding, который я только начинаю для себя открывать, и который выглядит очень перспективным. Вот, кстати, хороший материал по теме.

JSF 2.0 (июнь 2009 г.)

Это был второй крупный релиз, с Ajax в качестве модного слова. Было много технических и функциональных изменений. JSP заменяется Facelets в качестве технологии представления по умолчанию, а Facelets — с возможностями создания пользовательских компонентов с использованием чистого XML (так называемых составных компонентов ). См. Также Почему Facelets предпочтительнее JSP в качестве языка определения вида из JSF2.0 и далее?

Силы Ajax были введены в аромат компонента который имеет много общего с Ajax4jsf. Были добавлены расширения аннотаций и расширенных конфигураций, чтобы как можно больше kill файл verbose . Кроме того, идентификатор разделителя идентификатора контейнера по умолчанию стал настраиваемым, поэтому пуристы HTML / CSS могли вздохнуть с облегчением. Все, что вам нужно сделать, это определить его как в с именем и что вы не используете персонажа в любом месте идентификатора клиента, например.

Наконец, но не в последнюю очередь, была введена новая область, область обзора . Он устранил еще один существенный недостаток JSF 1.x, как описано выше. Вы просто объявляете bean для включения области разговора, не мешая всем способам сохранить данные в последующих (разговорных) запросах. будет работать до тех пор, пока вы впоследствии отправляете и перемещаетесь в один и тот же вид (независимо от открытой вкладки / окна браузера!) Либо синхронно, либо асинхронно (Ajax). См. Также Разница между областью просмотра и запроса в управляемых компонентах и как выбрать правильную область видимости бобов?

Несмотря на то, что практически все недостатки JSF 1.x были устранены, существуют JSF 2.0 определенные ошибки, которые могут стать showstopper. из-за проблемы с куриным яйцом в частичном сохранении состояния. Это зафиксировано в JSF 2.2 и передано в Mojarra 2.1.18. Также не поддерживаются такие пользовательские атрибуты, как HTML5 . Это зафиксировано в JSF 2.2 с помощью новой функции сквозных элементов / атрибутов. Кроме того, реализация JSF Mojarra имеет свой собственный набор проблем . Относительно многие из них связаны с иногда неинтуитивным поведением , новой реализацией с частичным сохранением состояния и плохо реализованной флэш-памятью . Большинство из них исправлены в версии Mojarra 2.2.x.

Вокруг JSF 2.0 времени был представлен PrimeFaces , основанный на jQuery и jQuery UI. Он стал самой популярной библиотекой компонентов JSF.

4.2 UI интерфейс интерфейса

Чтобы хорошо понять MVP, у вас должна быть возможность взаимодействовать с пользовательским интерфейсом. Посмотрите на интерфейс ниже и выделите пользовательский элемент управления, отмеченный красным, чтобы получить интерфейс ниже.

public interface IUserAdd 
{ 
       event EventHandler UserAddEvent;
       string UserName { get; set; }
       string UserAge { get; set; }
}

Два поля ввода в интерфейсе разделены на два атрибута: UserName и UserAge. Событие нажатия кнопки «Сохранить» абстрагируется в событии UserAddEvent. Код для реализации этого интерфейса в winform выглядит следующим образом:

public partial class UserAdd : UserControl, IUserAdd 
{ 
       public event EventHandler UserAddEvent; 
       public string UserName 
       { 
           set { this.txbName.Text = value; } 
           get { return this.txbName.Text; } 
       }

       public string UserAge 
       { 
           set { this.txbAge.Text = value; } 
           get { return this.txbAge.Text; } 
       }

       public UserAdd() 
       { 
           InitializeComponent(); 
       }

       private void btnAdd_Click(object sender, EventArgs e) 
       { 
          if (UserAddEvent != null) UserAddEvent(this, e); 
       } 
   }

Возьмем атрибут UserAge, чтобы объяснить волшебство интерфейса UI. Когда внутренний код хочет получить значение возраста в интерфейсе, ему нужен только атрибут get, а когда он хочет обновить отображение интерфейса, ему нужен только атрибут set. В это время работа внутреннего кода интерфейса абстрагируется в операции атрибута UserAge, который не имеет отношения к конкретному отображению интерфейса.

MVP

MVP(Модель-Просмотр-Презентатор) ДаУлучшенная модель MVC, Предложено Taligent, дочерней компанией IBM. То же самое с MVC: контроллер / презентатор отвечает за бизнес-логику, модель управляет данными, а представление отвечает за отображение.Он только меняет имя контроллера на презентатор и меняет направление связи.

Возможности MVP:

1. Двусторонняя связь между M, V и P.
2. Представление и Модель не взаимодействуют, все они передаются через Presenter. Presenter полностью разделяет модель и представление, а основная логика программы реализована в Presenter.
3. Представление очень тонкое и не развертывает никакой бизнес-логики, называемой «пассивным представлением» (Passive View), то есть без какой-либо инициативы, в то время как Presenter очень толстый, и вся логика развернута там.
4. Presenter не связан напрямую с конкретным представлением, но взаимодействует через определенный интерфейс, так что Presenter может оставаться неизменным при изменении представления, чтобы его можно было использовать повторно. Не только это, но вы также можете написать Views для тестирования, чтобы моделировать различные операции пользователя, чтобы реализовать тест Presenter — без необходимости использовать инструменты автоматического тестирования.

Отличие от MVC:

• вMVPВ View не использует модель напрямую. Связь между ними осуществляется через Presenter (контроллер в MVC), и все взаимодействия происходят внутри Presenter.
• вMVC, View будет считывать данные непосредственно из модели, а не через контроллер.

Преимущества MVP:

1. Модель и представление полностью разделены, мы можем изменить представление, не затрагивая модель;
2. Модели можно использовать более эффективно, потому что все взаимодействия происходят в одном месте внутри Presenter;
3. Мы можем использовать один Presenter для нескольких представлений без изменения логики Presenter. Эта функция очень полезна, потому что вид меняется чаще, чем модель;
4. Если мы поместим логику в Presenter, то мы сможем протестировать логику без пользовательского интерфейса (модульное тестирование).

Недостатки MVP:

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

Приложение MVP: Применимо и разработка для Android.

9 ответов

Это действительно зависит от типа проекта. Некоторым нравится MVC из-за того, что SEO извлекает выгоду из чистых URL-адресов и позволяет пользователям интеллектуально «взламывать» URL-адреса, делая умные предположения URL-адресов. MVC идет с расходом на то, что вы потеряете веб-элементы управления, поэтому ASP.NET AJAX и сетка перетаскивания из вашей библиотеки пользовательского интерфейса отсутствуют.

Просто для обобщения, общедоступный веб-сайт может быть лучшим кандидатом на MVC из-за его преимуществ SEO, тогда как внутреннее или бизнес-приложение может быть лучше, если у него есть время на разработку других областей. Опять же, если все, что вам нужно, это чистые URL, вы можете реализовать то же самое без MVC с помощью переписывания URL,

http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx
http://msdn.microsoft.com/en-us/library/ms972974. ASPX

Итак, что касается «недостатка» в использовании MVC, он может быть более личным,

Хотите ли вы пройти курс обучения в MVC?
Вы полагаетесь на элементы управления? Можете ли вы написать то же самое с помощью старого доброго HTML, CSS?
Может быть, вы теряете время на MVC, когда лучшая часть вашего проекта выиграет от времени написания кода?
Если все, на что вы обращаете внимание, это SEO, то переписывание URL — это лучший подход для ваших нужд?

Я бы сказал, что недостатки действительно связаны с разработчиком и проектом.

С помощью WebForms у вас есть множество предварительно созданных элементов управления пользовательского интерфейса, таких как сетки, графические инструменты и т. д. Существует целая индустрия элементов управления RAD.

К сожалению, с ASP.NET MVC многие из этих вещей еще не совсем там.

Самым большим недостатком является то, что вам, вероятно, придется использовать JavaScript /AJAX для создания более сложных форм. Например, если у вас есть целая куча виджетов (скажем, сеток данных, дополнительных сторонних форм и т. Д.), Которые не являются непосредственно частью текущего представления, управление состоянием является проблемой.

В ASP.NET WebForms, представление состояния автоматически обрабатывает это, так что вы можете иметь несколько независимых элементов управления, отправляющих и запускающих события, не путая что-либо еще на странице.

В ASP.NET MVC вам нужно справиться со всем этим самостоятельно, и самый простой способ — просто переместить вещи на сторону браузера.

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

Дополнительная информация здесь: Должен ли я перейти на ASP.NET MVC?

Кривая обучения и отсутствие готовых элементов управления, которые могут снизить производительность разработчика WebForms.

Однако я могу дать вам очень хорошее преимущество: если вы еще этого не сделали, вы, наконец, изучите основы HTML /CSS и HTTP, которые необходимы для любой серьезной веб-разработки, а не просто перетаскивания -пропадание вещей в редакторе.

Такие вещи, как состояние управления (текст в полях ввода), требуют ручной обработки, сравнивают с веб-формами … при условии, что вы используете его «правильно».

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

(Я имею в виду, что вы МОЖЕТЕ выполнить большинство обычных вещей asp.net внутри приложения mvc, но если вы делаете это широко, вам, вероятно, следует просто запустить веб-формы.)

ASP.NET требует маршрутизации IIS7 (т. е. Windows Server 2008 или Vista). Вы можете запустить его на IIS6 под Server 2003, но вы потеряете крутость маршрутизации без расширения.

• Сложность разработки приложений с использованием этого метода высока
  шаблон.
• Не подходит для небольших применений, которые оказывают неблагоприятное воздействие на
  производительность и дизайн приложения.
• С точки зрения сервлета и JSP, оба часто содержат бизнес-логику и
  уровень представления.
• Изолированный процесс разработки авторами пользовательского интерфейса, бизнес-логика
  Авторы и авторы контролеров могут привести к задержке
  разработка модулей.

1. сайтам ASP.NET MVC требуется в среднем в 10 раз больше времени на разработку, чем традиционным сайтам ASP.NET.

2. Он не использует мощные элементы управления asp.net.

3. Код не читается. Если вас заставят добавить некоторые улучшения на веб-сайт, разработанный кем-то другим, вы сойдете с ума.

Что такое MVC: основные идеи и принципы

• VC — это набор архитектурных идей и принципов для построения сложных информационных систем с пользовательским интерфейсом;
• MVC — это аббревиатура, которая расшифровывается так: Model-View-Controller.

Дисклеймер: MVC — это не паттерн проектирования. MVC — это именно набор архитектурных идей и принципов для построения сложных систем с пользовательским интерфейсом. Но для удобства, чтобы каждый раз не повторять: “Набор архитектурных идей…”, мы будем называть MVC паттерном. Начнем с простого. Что же скрывается за словами Model-View-Controller? При разработке систем с пользовательским интерфейсом, следуя паттерну MVC нужно разделять систему на три составные части. Их, в свою очередь, можно называть модулями или компонентами. Говори как хочешь, но дели на три. У каждой составной компоненты будет свое предназначение. Model. Первая компонента/модуль — так называемая модель. Она содержит всю бизнес-логику приложения. View. Вторая часть системы — вид. Данный модуль отвечает за отображение данных пользователю. Все, что видит пользователь, генерируется видом. Controller. Третьим звеном данной цепи является контроллер. В нем хранится код, который отвечает за обработку действий пользователя (любое действие пользователя в системе обрабатывается в контроллере). Модель — самая независимая часть системы. Настолько независимая, что она не должна ничего знать о модулях Вид и Контроллер. Модель настолько независима, что ее разработчики могут практически ничего не знать о Виде и Контроллере. Основное предназначение Вида — предоставлять информацию из Модели в удобном для восприятия пользователя формате. Основное ограничение Вида — он никак не должен изменять модель. Основное предназначение Контроллера — обрабатывать действия пользователя. Именно через Контроллер пользователь вносит изменения в модель. Точнее в данные, которые хранятся в модели. Приведем еще раз схему, которую тебе уже показывали на лекции: Из всего этого можно сделать вполне логичный вывод. Сложную систему нужно разбивать на модули. Опишем кратко шаги, как можно добиться подобного разделения.

Управление состоянием формы через конечный автомат

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

1 стартмани