GUI как конечный автомат
для реализации GUI приложения я хотел бы иметь всю логику, чтобы перейти от одной формы к другой централизованной. Этот менеджер GUI будет вести себя как конечный автомат. Хотя я думаю, что где-то видел такую реализацию, я не могу найти шаблон дизайна, который соответствует такому решению.
форма будет выглядеть вот так:
public class Login : Form
{
...
private void EnterButton_Click()
{
...
string user = loginTextBox.Text;
string password = passwordTextBox.Text;
bool isValid = SecurityManager.CheckUserLogin(user,password);
GUIManager.FormEnd(FormLogin,new LoginData(user, pass, isValid));
}
...
}
и менеджер GUI сделает что-то вроде этого:
public class GUIManager
{
...
public void FormEnd(FormType type, FormData data)
{
switch (type)
{
...
case FormLogin:
LoginData ld = (LoginData)data;
if (ld.Valid)
{
m_loginForm.Hide();
m_mainForm.Show();
}
...
}
}
...
}
достижения этой точки у меня следующие вопросы: есть ли шаблон проектирования, который формализует эту идею? Если есть, поддерживает ли .NET это как-то? Если нет, звучит ли это как хорошая идея реализации? Спасибо!
3 ответов
Это отличная идея! Так здорово, что это было сделано раньше и, вероятно, является наиболее распространенным шаблоном, используемым в расширяемой разработке приложений (подумайте об IDEs, таких как Visual Studio, Eclipse и тому подобное).
например, SCSF (который использует кабину), из MS Patterns and Practices Group, использует этот шаблон из коробки для создания подключаемых и расширяемых составных приложений в WinForms и WPF. Фактический шаблон, который он использует, включает построение иерархических машин состояний, называемых WorkItems, которые управляют usecases и потоком через приложение. Я бы посмотрел, как это делают ребята, прежде чем реализовать это как свое собственное детище. Я использовал его много раз, и оно того стоит.
на государственный шаблон проектирования описывает, как реализовать конечный автомат.
есть много, немного разные шаблоны дизайна для управления экранами в UI, но я думаю, что шаблон проектирования контроллера приложений соответствует тому, что вы пытаетесь сделать.
в мире Java вы можете думать о приложении Struts или JSF как FSM (это событие на этой странице/состоянии приводит нас к этой странице/состоянию.
при моделировании потоков в традиционном веб-интерфейсе я нашел использование FSMs чрезвычайно полезным инструментом анализа. Вы можете очень быстро уловить суть поведения приложения. Между и существовала почти однозначная связь.--3-->страница и государство. У меня была бы модель состояния и связанный модель данных.
теперь у нас есть более богатые UIs, использующие AJAX, соответствие между состояниями приложения и" страницами " менее очевидно. Однако вы все еще можете рассуждать о поведении приложения: здесь пользователь делает этой, когда они закончили thay может предпринять действия X или Y, а затем они могут сделать это. Таким образом, состояния, события и переходы все еще существуют, просто их представление немного более "виртуальное".