организация кода GUI в C #

Question

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

Не могли бы вы создать собственный элемент управления для каждого отдельного компонента, даже если они не будут использоваться вне этого приложения? или вы могли бы сделать это с классами, которые реализуют логику для каждого компонента и каким-то образом обновить этот фактический элемент управления в графическом интерфейсе? двум компонентам может потребоваться взаимодействие друг с другом, например, Вы щелкаете ячейку в сетке, и она вызывает диаграмму (будет ли основная форма обрабатывать отправку сообщения?)

У меня есть привычка позволять кодам форм увеличиваться при добавлении функций, и я действительно хочу познакомиться с лучшим способом. Я работаю с c # (не использую WPF), но я предполагаю, что основные принципы проектирования не обязательно зависят от языка.

Answer 1

См. - Gui Architectures . Автор Martin Fowler

Answer 2

Вы можете попробовать шаблон MVP .

Answer 3

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

Это позволяет мне создавать собственные конструкторы, которые я считаю более полезными, поскольку я пытаюсь использовать инфраструктуру DI / IOC в моем текущем проекте.

Answer 4

Это в некоторой степени зависит от масштаба приложения, а также от срока его службы.

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

Я бы рекомендовал прочитать (или, по крайней мере, скимминг) Руководство по составным клиентским приложениям *1006* для идей. Вопросы о передаче сообщений, а также вопросы о различных подходах к объединению отдельных компонентов обсуждаются подробно.

Существует множество драгоценных камней, которые могут быть полезны в Руководстве по составной клиентской аппликации , даже если вы не используете WPF или Silverlight. Многие из разделов руководства не относятся к конкретной технологии - они в большей степени касаются того, как объединить несколько частей, обеспечить многократное использование и гибкость в дизайне и т. Д. Они применяются независимо от используемой технологии.