Добрый день!

Вот собственно мои вопросы:
1. Как правильно организовать структуру многооконного приложения?
2. Как осуществить доступ из одной формы к другой?
3. Как организовать в приложении общие данные, которые были бы доступны всем формам.



Заранее спасибо! С уважением, Ch0bits.

Вот вариант:
1) анализируем, какие формы нам нужны и какие из них делать модальными/немодальными
2) среди всех форм выделяем несколько, с которыми пользователь работает постоянно, и вместо них делаем стыковочные окна с тем же контентом (как solution explorer, class view и т.п. окна студии)
3) среди оставшихся выделяем формы, представляющие данные или отображающие документы - этих форм одновременно может быть открыто несколько или не может быть вовсе (если приложение простое либо не предусматривает несколько открытых документов/наборов данных)
4) размещаем стыковочные окна в главной форме приложения, оставляем в центре рабочую область для форм на закладках, если такие были найдены в пункте 3
5) на рабочей области отображаем основную форму если она одна (как в Excel), либо несколько форм открытых документов, каждая на своей закладке (как исходники в студии)

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


Немодальные окна по идее не должны знать друг о друге напрямую, если любое из них можно закрыть в любой момент. Хотя для простоты можно хранить где-то в глобальной переменной прямую типизированную ссылку на каждую форму, имхо лучше сделать "как правильно" (мало ли что понадобится добавить или переделать потом). Предусматривается общий класс-менеджер и набор интерфейсов, реализуемых в каждой форме или контроле. Таким образом, все формы ничего не знают друг о друге кроме общих интерфейсов, при необходимости можно по имени или типу получить через менеджер ссылку на любую из форм и дёрнуть метод поддерживаемого интерфейса.


Статической переменной.

Да, кстати...
Модератор: Пожалуйста, один топик - один вопрос.

Имхо, MVC рулит. Советую почитать об этом паттерне. Краткая суть такова:
Приложение разделяется на три части:
1. Model - в ней хранятся данные приложения
2. View - это как раз user interface, вроде класса, контролирующего все формы
3. Controller - это класс, который реагирует на события View и изменяет Model
Общая схема взаимодействия такая:
1. Юзер щелкает на элементе формы
2. Об этом "узнает" View (например, можно послать событие)
3. View вызывает метод Controller'а
4. Controller работает с Model
Добавлено @ 12:15
Вообще, есть готовые фреймворки для реализации MVC, например Enterprise Library Composite UI Application Block, но с ним сначала нужно разобраться.

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

Поэтому форма должна отправлять свои события на обработку Controller'у...

Вот этого MVC и позволяет избежать.
Короче, это было моё ИМХО

Если все события формы отправлять контроллеру, то контроллер будет поставлен в зависимость от последовательности и взаимозависимости событий, генерируемых визуальными компонентами формы, а это чревато быстрым и неконтролируемым разрастанием исходного кода класса контроллера а-ля "все-формы-в-одном-классе". Я говорю о том, что нужно изначально разделить логику формы на визуальную и содержательную части, а это сделать архисложно, так как:
- форма есть неделимый элемент, уже сочетающий данные и их поведение с визуальной частью и её поведением;
- форма очень часто (если не слишком часто) подвергается изменениям и дополнениям, что приводит к появлению дополнительных обработчиков и методов, и модификации существующих обработчиков и методов, добавлению новых.

А посему:
1) изначально невозможно отделить визуальную часть от кода, управляющего данными;
2) для максимальной эффективности, разработчик обязательно должен всегда видеть, хотя бы мысленно, общую картину взаимодействия между различными визуальными элементами приложения, работающими одновременно либо раздельно и зависящими либо не зависящими друг от друга;
3) если разработчик теряется в собственноручно разработанной модели поведения приложения -- это значит, что контроль утерян и приложение развивается хаотично, что рано или поздно приводит к полному либо частничному рефакторингу приложения (в зависимости от сложности дополнения, которое вызвало рефакторинг), либо даже к необходимости написания аналогичного приложения с нуля, а-ля "пригласим негра-студента, который напишет аналог"

И тут MVC уже не советчик, к сожалению. Ещё MFC на этом зубы сломала: на их CMainFrame/CDocument/CView приходилось делать такие извраты, какие их майкрософту и не снились ...


К сожалению, не факт, см. выше...


Моё имхо: каждый разработчик имеет своё имхо. Это его личное дело, и иметь своё мнение - личное право каждого трудящегося ... Тем не менее, личный опыт в проектах, в которых принимал участие испытуемый, накладывает свой отпечаток на советы, которые он даёт остальным безвозмездно . И вот, приходим к конкретному примеру: лично мой опыт разработки приложений начиная с MFC и заканчивая WinForms говорит, что чем более чётко вся модель приложения расположена в головном мозгу программера, тем легче реализовываются любые части продукта, тем меньше влияние чужого мнения на результирующее решение задачи, и выше самооценка от сделанного выбора.

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

Ты CAB глядел? Там вроде очень хорошо все это реализовано.

К сожалению, нет... пока что. Надо будет глянуть, что они там напридумали ...

MS об этом уже подумала, и даже разработала каркас приложения, только бери и пользуйся!

Это в общем: Application Architecture for .NET

Это в частности: Composite UI Application Block
Добавлено @ 01:36


Ты зря проявляешь недоверие. Идея отличная, реализация еще лучше! Использованна вся мощь С# и платформы NET, в совокупности с последними достижениями в ООП.

Если разберешся в этом - я убежден, равнодушным CAB тебя не оставит.

Вся архитектура постренна на паттернах. В рамках CAB, писать плохо - просто невозможно.

Обязательно посмотрю

успокоил