Здравствуйте, Poudy, Вы писали:

P>Спасибо, конечно, за ответ, но все это тривиальные вещи. Я спрашивал немного о другом.
Наверное, не так понял

S>>Данный вариант оптимально было бы делать на основе расширений (plugin). Пишется один раз интегрирующий интерфейс, который в соответствии с конфигурацией загружает необходимые модули расширения. Каждое расширение будет иметь свой уникальный набор функциональности (обычно интерфейсная часть). Написание модулей расширения тогда будет относительно независимым. Так же повысится возможность повторного использования.

P>Хорошо. Рассмотрим следующую ситуацию. У нас есть базовая конфигурация, miniBasis, к которой создаются модули CRM и WMS. Такие модули можно делать в виде plugin. Это будет касаться пользовательского интерфейса. Что насчет дополнительных полей в сущности Customer?
Делаем новый класс, являющийся расширением Customer

public class CRMCustomer : Customer {...}
public class WMSCustomer : Customer {...}

P>Как добавить CRM возможности, чтобы ими было удобно пользоваться (а не через Advanced->CRM Options)?
User Controls (см. далее по тексту*)
P>Как обеспечить интеграцию модулей, т.е. расширение фич WMS в присутствии модуля CRM?
Описал выше, интерфейсную реализацию смотри ниже.

S>>Любое окно может иметь стандартную часть, а необходимая функциональность достигается за счет дополнительных расширений данного окна. Например, окно с табами, где есть закладка "основные параметры", а в зависимости от вызываемого контекста загружать дополнительные расширения окна, которые добавляют свои закладка типа "CRM specific".
S>>Пример такой архитектуры можно посмотреть здесь

Автор: stasukas
Дата: 12.10.05

. Если посидеть с напильником, то можно за некоторое время заточить под себя и использовать в дальнейшем (это, чтоб не выдумывать самому велосипед )

P>Да, нормальный известный пример. Но он больше касается automation, т.е. управлением извне UI и функциональностью приложения.
Почему-же? Достаточно взглянуть на Editor.Modules (из примера

Автор: stasukas
Дата: 12.10.05

). Здесь лежит как раз то, что Вам требуется относительно расширения конфигурации приложения.

P>Программировать под такую систему можно, но не очень удобно.
Тяжело сделать такой framework, а создавать расширения под него очень даже легко, если правильно спроектировать fw.

P>Куда девается RAD?
RAD как раз присутствует на уровне User Controls(*). Кто мешает их делать в IDE нормальными визуальными средствами? При создании формы мы добавляем несколько User Controls подряд — вот и решение, которое позволяет избавиться от закладок и всего остального (если надо), а необходимые поля начинают располагаться последовательно.



P>Мы уже не можем просто так визуально создать меню в design time.
Это не большая потеря, но и тут кое-что можно придумать.

P>Как быть опять же, если после года работы клиент решил доставить себе еще один модуль? (эволюция схемы, незаполненные новые параметры, накат модуля на кастомизированную базовую версию, обновления)...
Все можно сделать, как расширение базового. Описав конфигурационным файлом необходимые модули и модифицоровав БД можно получить нужный результат.