Проектирование приложения Windows для сохранения состояний в дочерних формах MDI

Question

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

Мне нужно создать приложение на базе Windows на C#, которое в основном отслеживает события от внешнего источника связи и отображает данные на графике. Приложение подписывается на события из объектов связи и обновляет пользовательский интерфейс, когда и когда есть события данных. Компонент графа внутри этих классов мониторинга будет использовать данные внутри буферов данных связи для построения данных в виде линейного графика.

Для достижения этой цели, я создал класс Factory, который будет создать экземпляр определенного класса мониторинга (CWindowFirst или CWindowSecond и т.д.), основываясь на информации о модели я обеспечиваю (устройство модели типа).

Эти классы реализуют стандартный контракт (IFactoryInterface) для инициализации, сбора данных и операций очистки. Поэтому в любой момент времени я могу создать экземпляр определенного класса и запустить операцию мониторинга для получения данных и заполнения графа в процессе. Пока что так хорошо, я могу отображать данные в виде графика для конкретного устройства. Также в настоящий момент я уничтожаю (удаляю) объект CWindowFirst всякий раз, когда основное приложение выбирает другое окно (т. Е. CWindowSecond или CWindowThird).

Как говорится в «Разработка SW, единственная константа - это изменение», появилось новое требование, когда мне нужно предоставить пользователю возможность функции Пауза/Стоп для графика. Я должен уметь приостанавливать график (т. Е. Приостанавливать передачу данных) и переходить в главное окно, а также иметь возможность открыть другое окно (CWindowSecond), где-нибудь там будет бит с графиком (должно быть в состоянии приостановить сообщение здесь также). Вернитесь в первое окно CWindowFirst и возобновите ранее сохраненную передачу данных.

Теперь возникает вопрос о миллионе $, как мне достичь или, скорее, изменить существующий проект для реализации функции, как описано выше.

Я могу придумать следующую реализацию, но я не уверен, что это действительно прагматичный.

По вопросу команды Pause я

1. Остановить связь (отменить подписку события связи) на паузу.
2. Сохранение состояния буферов данных и графика событий в коллекции.
3. Сериализуйте полный объект в файл перед выходом.
4. По возвращению в ту же форму, я десериализация объекта
5. Получить буфер данных событий из десериализованного объекта
6. Populate в графике и включить обработчик событий, так что я продолжаю получать событие от уровня связи ,

Эксперты там мне нужна ваша помощь здесь. Пожалуйста, направляйте/предлагайте улучшения/делитесь идеей

Answer 1

Как прокомментировал HansPassant, отделите данные (или контекст, или менеджер, что угодно) от просмотра. Singleton с инволюцией конструктора контекста - лучший выбор здесь ИМХО.

Пример с использованием не-чистейший способ одноточечного:

public class MonitoringContext { 
    public static MonitoringContext CurrentContext = new MonitoringContext(); 

    // handle generating data 
    // handle populating data needed for graph 
    // handle other action from other forms as well 
} 

public class FormGraph : Form{ 
    // default constructor if you do not have access to MDI 
    public FormGraph(){ 
     this.context = MonitoringContext.CurrentContext; 
    } 
    public FormGraph(MonitoringContext context){ 
     this.context = context; 
    } 
    MonitoringContext context; 

    // do whatever you want with context 
} 

public class FormOther : Form{ 
    // default constructor if you do not have access to MDI 
    public FormOther(){ 
     this.context = MonitoringContext.CurrentContext; 
    } 
    public FormOther(MonitoringContext context){ 
     this.context = context; 
    } 
    MonitoringContext context; 

    // do whatever you want with context 
    // any changes reflected at the FormGraph 
    // because of same reference and mutability 
} 

Конечно, это предлагается подход от аутсайдера, которые не знают требования и текущую архитектуру глубоко и подробно. Любая корректировка должна быть выполнена для выполнения этого требования.