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

S>>Я предлагаю сделать так:
S>>

S>>
1. Определить структуру данных — таблица Customer имеет понятную структуру, CRMCustomer хранит связь с Customer и специфические расширения для сущности CRMCustomer, с WMSCustomer то же самое
   
   P>ok. думаю, это очевидно наследования не нужно. и существенно не отличается от моего поста.
   Возможно, но я предлагал сделать нечто напоминающее Class Table Inheritance (по Фаулеру). На уровне BLL все бегает относительно разрозненно (с некоторым "склеивающим" ID, чтоб агрегация работала), а собирается при переходе с уровня на уровень, т.е. с BLL на PL в DTO.
   
   S>>
2. Определить сервисы взаимодействия и хранения определенных ранее Customer, CRMCustomer и WMSCustomer
   
   P>Хорошо, но я не до конца понимаю, что там будет. Имеется в виду обычный аляMS DAL?
   Нет, не DAL. Именно набор бункциональности BLL.
   
   P>Мне кажется, имеет смысл говорить о расширяемых приложениях. с сервисами будут проблемы.
   Под сервисом я понимал некоторый набор операций, специфичный для сущности или группы сущностей, но никак не технологии. Кто мешает сделать некоторый набор таких сервисов (лучше их назвать бизнес-сервисами) и делать необходимые агрегирующие надстройки? Если есть необходимость отключить часть функциональности, то в агрегирующих сервисах мы можем сделать необходимую настройку или поставить dummy stub вместо этого сервиса.
   
   
   S>>
3. Для получения необходимых DTO можно делать агрегацию: для CRMCustomerDTO мы основную часть берем из сервиса Customer, а специфичную добавляем из CRMCustomer
   S>>

P>ну ясно.

S>>Думаю, что такой вариант будет достаточно простым и эффективным. Одноврененная работа с разными сущностями в рамках предложенной технологии позволит выявить и разрешить конфликты совместной работы, а так же не таскать дубликаты в BLL.

P>вот этого я совсем не понял. "одновременная работа с разными сущностями" "позволит выявить и разрешить" — это как?
Мы всегда можем сделать любой из видов блокировки в своем приложении на уровне сущностей или специфических свойств сущностей (т.е. как бы на уровне представления таблицами). Таким образом мы можем независимо работать с разными сущностями при редактировании различных данных (относязихся к различным сущностям), но и сможем разрешать конфликты при изменении одних и тех же данных.
Например, один пользователь редактирует Customer, а другой CRMCustomer. При этом, если изменения не пересекаются по сущностям, то конфликта нет, а если пересечение есть (изменения в Customer), то возникает конфликт, который мы решаем стандартным выбранным образом.

У меня такое видение данной проблемы. Если кто-нибудь видит ее по другому, то я рад был бы выслушать и других.
Если есть желание, то могу объяснить более подробно на ближайшей RSDN UG или MDNA UG в Москве.