Уже не знаю сколько ломаю  голову над следующей проблемой...    Придумать бы откуда начать... Итак... Есть много пользователей, которые разделены на группы. Суть в том, чтобы написать приложение, которое в зависимости от того, к какой группе относится пользователь, запускающий программу, открывало бы окно с соответствующим функционалом. Программу нужно писать с учётом возможности увеличения количества этих групп пользователей. Есть идея реализовать это с помощью плагинов. Т.е. для каждой группы пользователей своя прога, зашитая в дллку, а основная прога только запускает нужную дллку. Например, сделать этой проге mdi-интерфейс, а плагины соответсвенно - child-окна, НО! Каждый пользователь выполняет определённую работу. Его функционал тоже может расширяться, т.е. получается, что это должны быть плагины для плагинов... В идеале было бы, чтобы плагины первого уровня как раз и были бы mdi-окнами, а плагины второго уровня дочерними, но так появляется вопрос, как должно быть реализовано главное окно...     Короче я запутался круто и наверно туплю... Не могу придумать интерфейс и логику! Дожили, блин!    Пните меня в нужное направление! Заранее спасибо!

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

А если вместо плагинов - отдельные программы, которые взаимодействуют друг с другом, а главная их только запускает (+может обеспечивать их взаимодействие).

1. Создаем практически пустую программу с минимальным общим функционалом, который включает систему регистрации пользователй, систему работы с плагинами, с профилями пользователй и итп.
2. На каждую бизнес-функцию создаем плагин(dll), который при загрузке добавляет соответствующий функционал к основной программе
3. Для каждого пользователя или для  бизнес-роли, к которой  этот пользователь относится создаем профиль в котором указываются все доступные для него бизнес-функции (плагины)
При загрузке программа просит пользователя залогинится, определяет читает его личный  профиль или если его нет, профиль его бизнес-роли и загружает все доступные для него плагины, которые соответствующим образом добавляют требуемый для него функционал и интерфейс

Вообщем-то -это достаточно известное тривиальное решение. Нужно для конкретно пользователя добавить функцию, открываем ему в профиле соответствующий плагин или при необходимости  его разрабатываем. Функционал можно наращивать до бесконечности. У меня был комплекс  примерно с полуторасотней плагинов. Преимущество в том, что в реальности конкретный человек очень часто может совмещать несколько бизнес-ролей. Например, бухгалтера и  кладовщика. Соотвественно можно настроить для него уникальный профиль. Вынужден дополнительно замещать кого на время отпуска - нет проблем, добавим. Надобность отпала - уберем. Причем если профиля хранить в БД, то все это может сделать администратор системы со своего рабочего места
Я обычно при проектировнии основного приложения предпочитал использовать MDI. Основное окно было построено по типу эксплорера с деревом  в левой части, которое использовалось как меню. Вид этого дерева завил от того, что пользователю положено по штату 
Но вообще-то это уже не принципиально и является делом предпочтения. Можно просто иметь простое окно с меню. Наполнение  меню  будет изменяться в зависимости от загруженных плагинов.


 
 

Круто. Сначала разрабатываем все, потом привязываем и ... Интересно, что из всего этого заработает и сколько времени придется потратить на то чтобы довести до ума систему? И зачем люди только RUP и итерационный  принцип разработки придумали.  
Почитайте. Будет полезно.
http://huze.ru/2008/01/16/iteracionnaya-model-razrabotki/

Автору топика нужно же не простненькую программу разработать, модель которой "в голове у програмиста", а  достаточно серьезный  легко расширяемый и настраиваемый комплекс 
Кстати система: основное приложение -- плагины оптимально подходит под  итерационный  принцип.
1.Первый этап: разработка основного приложения и  системы взаимодействия ее с плагинами.
2 Второй и последующий - разработки плагинов.
Комплекс можно запускать в эксплуатацию, как только будет набран минимальный функционал.
Система будет обладать свойством слабой связанности, то есть как правило внесение изменений не будет распространяться на все приложение а максимум ограничется одним плагином. Важно хорошо продумать систему работы с плагинами и качественно написать функционал, который будет встроен в само приложение. Если в этой области будут допущенны ошибки, они могут привести к внесению изменений по всей ситеме. 
В свое время я для такой системы разработал ряд VCL- компонетов и и визард для создания плагинов. В результате разработка плагина была достаточно сильно формализована , что резко упрощало время разработки и обеспечивало решение проблемы  "отчуждения" кода от конкретного программиста. Последнее - довольно частая беда для средних и мелких компаний со своим IT, когда уход ключевого программиста мог привести к невозможности дальнейшей поддержки и разработки системы.

я не говорил про разрабатываем все и привязываем.
то что я хотел сказать - разрабатывая архитиктуру нельзя привязываться к реализации (типа MDI или SDI).
вероятность того, что функционал можно будет просто добавлять, очень сильно падает, если из начально привязываться к чему-то.
под словами "а когда она уже более-менее будет готова" в данном случае можно понимать когда будет спроектирована бизнес-логика первого этапа:

после этого можно начинать думать над интерфейсом пользователя, как реализовать это все, SDI, MDI или может что лучше можно использовать.
из нормальной архитектуры вылезет нормальный интерфейс.

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

Во-во!  Так и есть!!!

Нечто подобное я и начал реализовать! Кстати, проблема: у дочерних окон своё меню, но при максимизации дочернего, его меню полностью заменяет меню дочернего и не хочет объединяться... 

Именно! Причины того, что приложение должно полностью состоять из плагинов, именно те, которые описывает Vyacheslav! А именно: возможность ввода приложения в работу уже при минимальном функционале, возможность быстрого расширения и гибкой настройки, ну, и наследие потомкам   , которым ещё предстоит развивать это проект. А мне пока как раз и надо заложить основу и интерфейс взаимодействия с плагинами...

На самом деле иногда бывает проще придумать архитектуру, если уже знаешь, как хотя бы визуально, должно выглядеть приложение!  
Vyacheslav, korian, 0lmer, спасибо!   Отдельное спасибо Vyacheslavу за подробное описание и ссылочку! Попробую оттуда ещё для себя что-то выжать! Было бы сообщений у меня побольше, повысил бы репутацию...



Это сообщение отредактировал(а) AxelWind - 22.3.2008, 01:47

Полазил по форуму... Нарыл вот что... От Vyacheslavа:


Ну, и сразу столкнулся с одной проблемой: возможно ли сделать, чтобы меня на форме не пропадало? Какие ещё проблемы могут появиться с таким использованием второй формы?   

Кстати, ToolBar и StatusBar остались...    Честно говоря не ожидал...   Но при попытке изменить размер дочернего окна со статусбаром меняется размер главной формы... 

Это сообщение отредактировал(а) AxelWind - 22.3.2008, 03:22