| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Общие вопросы по .NET и C# > Вопросы о формах |
| Автор: Ch0bits 12.3.2006, 10:57 |
Добрый день!  Вот собственно мои вопросы: 1. Как правильно организовать структуру многооконного приложения? 2. Как осуществить доступ из одной формы к другой? 3. Как организовать в приложении общие данные, которые были бы доступны всем формам.  Заранее спасибо! С уважением, Ch0bits. |
| Автор: mr.DUDA 12.3.2006, 11:53 | ||||||
Вот вариант: 1) анализируем, какие формы нам нужны и какие из них делать модальными/немодальными 2) среди всех форм выделяем несколько, с которыми пользователь работает постоянно, и вместо них делаем стыковочные окна с тем же контентом (как solution explorer, class view и т.п. окна студии) 3) среди оставшихся выделяем формы, представляющие данные или отображающие документы - этих форм одновременно может быть открыто несколько или не может быть вовсе (если приложение простое либо не предусматривает несколько открытых документов/наборов данных) 4) размещаем стыковочные окна в главной форме приложения, оставляем в центре рабочую область для форм на закладках, если такие были найдены в пункте 3 5) на рабочей области отображаем основную форму если она одна (как в Excel), либо несколько форм открытых документов, каждая на своей закладке (как исходники в студии) В данной схеме одновременно активными являются несколько форм/контролов, если не открыто модальное окно диалога. Для взаимодействия между окнами приложения нужен класс-менеджер, который можно либо сделать синглтоном, либо ссылку на него передавать в конструктор каждой формы и контрола при их создании.
Немодальные окна по идее не должны знать друг о друге напрямую, если любое из них можно закрыть в любой момент. Хотя для простоты можно хранить где-то в глобальной переменной прямую типизированную ссылку на каждую форму, имхо лучше сделать "как правильно" (мало ли что понадобится добавить или переделать потом). Предусматривается общий класс-менеджер и набор интерфейсов, реализуемых в каждой форме или контроле. Таким образом, все формы ничего не знают друг о друге кроме общих интерфейсов, при необходимости можно по имени или типу получить через менеджер ссылку на любую из форм и дёрнуть метод поддерживаемого интерфейса.
Статической переменной. Да, кстати... Модератор: Пожалуйста, один топик - один вопрос. |
| Автор: Exception 12.3.2006, 12:12 |
| Имхо, 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, но с ним сначала нужно разобраться. |
| Автор: mr.DUDA 12.3.2006, 15:47 |
| Exception, вообще-то спрашивали как раз об организации набора форм. Это сама по себе сложная задача, требующая сбалансированного решения. По ходу разработки в каждой форме появляется туча своих обработчиков событий, методов и свойств, не все из которых можно вынести за пределы формы. Чем более навороченная форма, тем сложнее отделять функциональность собственно формы как визуального элемента, от функциональности формы как части MVC. |
| Автор: Exception 12.3.2006, 18:06 | ||||
Поэтому форма должна отправлять свои события на обработку Controller'у...
Вот этого MVC и позволяет избежать. Короче, это было моё ИМХО |
| Автор: mr.DUDA 12.3.2006, 20:12 | ||||||
Если все события формы отправлять контроллеру, то контроллер будет поставлен в зависимость от последовательности и взаимозависимости событий, генерируемых визуальными компонентами формы, а это чревато быстрым и неконтролируемым разрастанием исходного кода класса контроллера а-ля "все-формы-в-одном-классе". Я говорю о том, что нужно изначально разделить логику формы на визуальную и содержательную части, а это сделать архисложно, так как: - форма есть неделимый элемент, уже сочетающий данные и их поведение с визуальной частью и её поведением; - форма очень часто (если не слишком часто) подвергается изменениям и дополнениям, что приводит к появлению дополнительных обработчиков и методов, и модификации существующих обработчиков и методов, добавлению новых. А посему: 1) изначально невозможно отделить визуальную часть от кода, управляющего данными; 2) для максимальной эффективности, разработчик обязательно должен всегда видеть, хотя бы мысленно, общую картину взаимодействия между различными визуальными элементами приложения, работающими одновременно либо раздельно и зависящими либо не зависящими друг от друга; 3) если разработчик теряется в собственноручно разработанной модели поведения приложения -- это значит, что контроль утерян и приложение развивается хаотично, что рано или поздно приводит к полному либо частничному рефакторингу приложения (в зависимости от сложности дополнения, которое вызвало рефакторинг), либо даже к необходимости написания аналогичного приложения с нуля, а-ля "пригласим негра-студента, который напишет аналог" И тут MVC уже не советчик, к сожалению. Ещё MFC на этом зубы сломала: на их CMainFrame/CDocument/CView приходилось делать такие извраты, какие их майкрософту и не снились  ...
К сожалению, не факт, см. выше...
Моё имхо: каждый разработчик имеет своё имхо. Это его личное дело, и иметь своё мнение - личное право каждого трудящегося  ... Тем не менее, личный опыт в проектах, в которых принимал участие испытуемый, накладывает свой отпечаток на советы, которые он даёт остальным безвозмездно  . И вот, приходим к конкретному примеру: лично мой опыт разработки приложений начиная с MFC и заканчивая WinForms говорит, что чем более чётко вся модель приложения расположена в головном мозгу программера, тем легче реализовываются любые части продукта, тем меньше влияние чужого мнения на результирующее решение задачи, и выше самооценка от сделанного выбора.Краткое резюме: делай как тебе больше нравится, но используй как можно больше чужого опыта, остальное - см. мою подпись |
| Автор: Exception 12.3.2006, 20:28 |
| Ты CAB глядел? Там вроде очень хорошо все это реализовано. |
| Автор: mr.DUDA 12.3.2006, 20:33 | ||
К сожалению, нет... пока что. Надо будет глянуть, что они там напридумали  ... |
| Автор: Medved 15.3.2006, 01:26 | ||
| MS об этом уже подумала, и даже разработала каркас приложения, только бери и пользуйся! Это в общем: http://forum.vingrad.ru/index.php?act=ST&f=199&t=80158&st=0 Это в частности: http://msdn.microsoft.com/library/en-us/dnpag2/html/CAB.asp?frame=true Добавлено @ 01:36
Ты зря проявляешь недоверие. Идея отличная, реализация еще лучше! Использованна вся мощь С# и платформы NET, в совокупности с последними достижениями в ООП. Если разберешся в этом - я убежден, равнодушным CAB тебя не оставит. Вся архитектура постренна на паттернах. В рамках CAB, писать плохо - просто невозможно. |
| Автор: mr.DUDA 15.3.2006, 08:32 |
| Обязательно посмотрю |
| Автор: Medved 15.3.2006, 12:15 |
| успокоил |
