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

P>Я сам передаю данные в xml. Он хорош. Вопрос — при чем тут xml? Aggregation можно сделать как угодно, но не все же задачи сводятся к передаче данных Я сейчас не смотрю ни на таблицы, ни на DataSet, ни вообще на DTO. Оставим за рамками aggregation level. Вопрос в том, как расширять сущности.

P>Мне кажется, что можно решить такую проблему, если делать следующие вещи:
P>- любые расширения сущностей делаются как создание новой сущности, агрегирующей старую. это мы уже обсудили. контроль доступа и прочее делается на уровне каждой из сущностей своими службами. Рассмотрим модуль CRM. Он расширил Customer полями Debt и прочее. Вроде как теперь во всех используемых сущностях должен быть CRMCustomer. Принципиально никто не мешает нам нагенерить заново все классы БО, чтобы они работали с CRMCustomer.

P>Иногда нужно из модуля CRM нужно работать с WMSCustomer.
А это не ошибка проектирования? Тогда получается, что подсистемы теряют независимость.

P>Этого WMSCustomer также можно сгенерить специально под модуль CRM, вроде как proxy. Теперь можно будет спокойно апдейтить базовую конфигурацию. Старый CRM просто не будет знать о новых сущностях, полях и методах. Если мы не используем наследвоание, references и т.д., то проблем нет.
P>Просто это означает, что если кто-то захочет покопаться в CRM, для него нужно отпачковать еще одну версию всех сущностей. Тогда можно будет апдейтить и CRM модуль тоже. думаю так.

Из всего сказанного по теме я сделал вывод, что можно работать двумя способами в данной ситуации:

1. Работаем с бизнес-сервисами, которые оперируют своими "обрезками" от сущности, логическая склейка происходит за счет интерфейса пользователя. Преимущества этого подхода заключаются в отсутствии какого-либо пересечения между модулями системы. Минусы —
   
   
2. Работаем с xml и агрегаторами, которые должны уметь склеивать в единую сущность все данные по расширению всех используемых сущностей, а на уровне интерфейса мы должны расклеивать для каждого модуля. Тут плюсы очевидны — есть композитная сущность, из которой каждый модуль может вытянуть необходимую ему часть, а при расширении системы мы изменяем тем или иным способом агрегаторы. Из минусов следует отметить, что мы используем упаковку/распаковку и таскаем сущности полностью, а это повышает сложность системы.
   

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