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


P>Хорошо. Рассмотрим следующую ситуацию. У нас есть базовая конфигурация, miniBasis, к которой создаются модули CRM и WMS. Такие модули можно делать в виде plugin. Это будет касаться пользовательского интерфейса. Что насчет дополнительных полей в сущности Customer? Как добавить CRM возможности, чтобы ими было удобно пользоваться (а не через Advanced->CRM Options)? Как обеспечить интеграцию модулей, т.е. расширение фич WMS в присутствии модуля CRM?
Гм. Тут, имхо, надо отличать UI от внутренней архитектуры.
Давайте сначала поговорим об архитектуре. С ее точки зрения, расширять сущности "базоовой конфигурации" — крайне рискованная затея. Она сработает только в том случае, если некоторый модуль полностью заменяет собой базовый. Т.е. например у нас был модуль SimpleCustomers, который представлял кастомеров как что-то очень примитивное. Фактически, только для того, чтобы другие модули могли на них ссылаться. Например, модулю обработки заказов вообще неинтересно про кастомера ничего, кроме ФИО и адреса доставки. Вот мы и поставляем в базовой конфигурации таких убогих кастомеров. Но мы можем заменить модуль SimpleCustomers модулем AdvancedCustomers, который наделит кастомеров всякими продвинутыми характеристиками. Но сразу всех кастомеров! И нам потребуется определенная процедура импорта данных при инсталляции.

Что касается модуля расширения, то ему крайне не рекомендуется вводить своих наследников от стандартных сущностей. Что бы такого придумать? А, вот! Пусть мы теперь добавляем в систему модуль Project Management. Он, ясное дело, добавляет в систему огромное количество своих сущностей — проекты, задачи, ресурсы и т.п. Он может ссылаться на чужие сущности — например, задача может быть ассоциирована c неким Employee, а проект — с Customer. Опять же, с точки зрения ООП лучше делать эти ссылки самыми базовыми — пусть проект ссылается на Customer, а не на AdvancedCustomer. Достигается полная модульность.

Программировать под это, конечно, не всегда удобно — если мы хотим расширить связку модулей (CRM+PM), то не можем писать customer.CurrentProject. Потому как у Сustomer нет никакого CurrentProject. Но это — исключительо синтаксическая проблема. В идеале, язык на котором мы проектируем, должен автоматически добавлять Reverse References — т.е. как только мы зарегистрировали класс Project со ссылкой Project.Customer, мы сразу получаем у того, что мы сейчас называем Customer, виртуальную коллекцию Projects.
В неидеальном случае придется каждый раз писать Project.GetProjectsByCustomer(customer).

P>Да, нормальный известный пример. Но он больше касается automation, т.е. управлением извне UI и функциональностью приложения. Программировать под такую систему можно, но не очень удобно. Куда девается RAD? Мы уже не можем просто так визуально создать меню в design time.
Почему же девается? Ок, мы не можем поменять синтаксис языка (а жаль). Но мы можем поменять дизайнер форм (можем?). Пусть он автоматически подцепляет эти внешние ссылки. С его точки зрения у Customer будет не только базовый набор полей, но и все то, что ему навесили дополнительные модули.
Это если мы хотим проектировать интерфейс вручную, а не генерить его автоматически (добавляя те самые табы по количеству модулей).