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

P>Понятно. Вначале мне тоже казалось, что это идеальное решение .
P>Всё дело в том, что теперь в справочнике клиентов находится каша из различных наследников.
P>По идее, CRM модулю расширенная информация нужна для _всех_ клиентов. Так же, как и WMS.
P>По крайней мере есть ситуации, когда некий экземпляр Customer должен быть расширен до CRMCustomer и WMSCustomer одновременно.

P>Не, ок. Я понимаю, что WMSCustomer — это может быть не сама сущность, БО. Тогда у нас есть доп. таблицы в базе для расширений, каждый модуль работает с общим справочником так, как будто там только его кастомеры, т.е. БО делает для него прозрачным добавление полей и заполнение их default значениями.

P>Я спрашивал про сущности. Если посмотреть на эти таблицы расширений, то никакой диаграммы наследования для сущностей не будет.
Тут стоит определиться, как мы будем проектировать уровень бизнес-логики.
Понятно, что между интерфейсом и бизнес-логикой будут бегать DTO. Они совершенно спокойно могут быть расширениями, т.к. ничего кроме данных не передают. Проблема может заключаться в том, что в зависимости от дизайна уровня бизнес-логики необходимо разрабатывать свою технологию работы с Customer, CRMCustomer и WMSCustomer.

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

1. Определить структуру данных — таблица Customer имеет понятную структуру, CRMCustomer хранит связь с Customer и специфические расширения для сущности CRMCustomer, с WMSCustomer то же самое
   
2. Определить сервисы взаимодействия и хранения определенных ранее Customer, CRMCustomer и WMSCustomer
   
3. Для получения необходимых DTO можно делать агрегацию: для CRMCustomerDTO мы основную часть берем из сервиса Customer, а специфичную добавляем из CRMCustomer

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



P>Типа так. Кстати, наследование реализации для БО тоже плохая идея, т.к. создаст много копий одних и тех же данных. Когда CRM и WMS работают одновременно, мы получим 3 копии: экземпляры Customer, CRMCustomer и WMSCustomer. Т.е. лучше юзать интерфейсы:
P>

P>public interface ICustomer {...}
P>public interface ICRMCustomer {...}
P>public interface IWMSCustomer {...}

P>public class Customer : ICustomer {...}
P>public class CRMCustomer : ICRMCustomer 
P>{
P>    private ICustomer customer;
P>    ...
P>}
P>public class WMSCustomer : IWMSCustomer 
P>{
P>    private ICustomer customer;
P>    ...
P>}
S>>

На мой взгляд, это очень странная идея с интерфейсами...