Стоит задача разработки кучи некоторых инф.систем.
Допустим, CRM, Sales, WMS и т.д., специальные, недоразвитые, интегрируемые с 1с/Axapta и друг с другом.
Все системы могут ставиться и использоваться отдельно.
Желательно иметь их все в одном окне, примерно как в SAP.
В терминах ERP, нужно получить несколько различных конфигураций для разных задач.
В случае 1с это будут фактически разные программы и их придется сшивать вручную.
В случае SAP это модули.
Как подойти к вопросу разработки и интеграции модулей?
Т.е. есть какая-то базовая система сущностей и всего с ними связанного (Клиенты, Сотрудники, Товары, окошки).
Для CRM или Sales необходимы определенные, но различные, расширения состава полей, тех же окошек и прочего.
Зная заранее, что все системы разрабатываются нами, пусть и в разное время, что можно предложить в плане теории и практике разработки и интеграции таких штук?
У меня уже сформировалось мнение, но хотелось бы узнать для начала мнение комьюнити.
Здравствуйте, Poudy, Вы писали:
P>Стоит задача разработки кучи некоторых инф.систем. P>Допустим, CRM, Sales, WMS и т.д., специальные, недоразвитые, интегрируемые с 1с/Axapta и друг с другом. P>Все системы могут ставиться и использоваться отдельно. P>Желательно иметь их все в одном окне, примерно как в SAP.
P>В терминах ERP, нужно получить несколько различных конфигураций для разных задач. P>В случае 1с это будут фактически разные программы и их придется сшивать вручную. P>В случае SAP это модули.
Данный вариант оптимально было бы делать на основе расширений (plugin). Пишется один раз интегрирующий интерфейс, который в соответствии с конфигурацией загружает необходимые модули расширения. Каждое расширение будет иметь свой уникальный набор функциональности (обычно интерфейсная часть). Написание модулей расширения тогда будет относительно независимым. Так же повысится возможность повторного использования.
P>Как подойти к вопросу разработки и интеграции модулей? P>Т.е. есть какая-то базовая система сущностей и всего с ними связанного (Клиенты, Сотрудники, Товары, окошки). P>Для CRM или Sales необходимы определенные, но различные, расширения состава полей, тех же окошек и прочего.
Любое окно может иметь стандартную часть, а необходимая функциональность достигается за счет дополнительных расширений данного окна. Например, окно с табами, где есть закладка "основные параметры", а в зависимости от вызываемого контекста загружать дополнительные расширения окна, которые добавляют свои закладка типа "CRM specific".
Пример такой архитектуры можно посмотреть здесь
. Если посидеть с напильником, то можно за некоторое время заточить под себя и использовать в дальнейшем (это, чтоб не выдумывать самому велосипед )
Что касается общей архитектуры решения, то использовать модульную интерфейсную часть, которая будет общаться с бизнес-логикой (ES, WS или другие технологии), а та в свою очередь с БД.
P>Зная заранее, что все системы разрабатываются нами, пусть и в разное время, что можно предложить в плане теории и практике разработки и интеграции таких штук?
Если система пишется с нуля, то лучше с самого начала писать модульную расширяемую систему. Если уже есть какие-то разработки, то можно их интегрировать с помощью интегрирующего ПО (как самописного, так и с помощью вещей типа BizTalk).
P>У меня уже сформировалось мнение, но хотелось бы узнать для начала мнение комьюнити.
Здравствуйте, stasukas.
Спасибо, конечно, за ответ, но все это тривиальные вещи. Я спрашивал немного о другом.
P>>В терминах ERP, нужно получить несколько различных конфигураций для разных задач. P>>В случае 1с это будут фактически разные программы и их придется сшивать вручную. P>>В случае SAP это модули.
S>Данный вариант оптимально было бы делать на основе расширений (plugin). Пишется один раз интегрирующий интерфейс, который в соответствии с конфигурацией загружает необходимые модули расширения. Каждое расширение будет иметь свой уникальный набор функциональности (обычно интерфейсная часть). Написание модулей расширения тогда будет относительно независимым. Так же повысится возможность повторного использования.
Хорошо. Рассмотрим следующую ситуацию. У нас есть базовая конфигурация, miniBasis, к которой создаются модули CRM и WMS. Такие модули можно делать в виде plugin. Это будет касаться пользовательского интерфейса. Что насчет дополнительных полей в сущности Customer? Как добавить CRM возможности, чтобы ими было удобно пользоваться (а не через Advanced->CRM Options)? Как обеспечить интеграцию модулей, т.е. расширение фич WMS в присутствии модуля CRM?
S>Любое окно может иметь стандартную часть, а необходимая функциональность достигается за счет дополнительных расширений данного окна. Например, окно с табами, где есть закладка "основные параметры", а в зависимости от вызываемого контекста загружать дополнительные расширения окна, которые добавляют свои закладка типа "CRM specific". S>Пример такой архитектуры можно посмотреть здесь
. Если посидеть с напильником, то можно за некоторое время заточить под себя и использовать в дальнейшем (это, чтоб не выдумывать самому велосипед )
Да, нормальный известный пример. Но он больше касается automation, т.е. управлением извне UI и функциональностью приложения. Программировать под такую систему можно, но не очень удобно. Куда девается RAD? Мы уже не можем просто так визуально создать меню в design time.
S>Что касается общей архитектуры решения, то использовать модульную интерфейсную часть, которая будет общаться с бизнес-логикой (ES, WS или другие технологии), а та в свою очередь с БД.
Как быть опять же, если после года работы клиент решил доставить себе еще один модуль? (эволюция схемы, незаполненные новые параметры, накат модуля на кастомизированную базовую версию, обновления)...
P>>Зная заранее, что все системы разрабатываются нами, пусть и в разное время, что можно предложить в плане теории и практике разработки и интеграции таких штук? S>Если система пишется с нуля, то лучше с самого начала писать модульную расширяемую систему. Если уже есть какие-то разработки, то можно их интегрировать с помощью интегрирующего ПО (как самописного, так и с помощью вещей типа BizTalk).
Здравствуйте, 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>>Пример такой архитектуры можно посмотреть здесь
. Если посидеть с напильником, то можно за некоторое время заточить под себя и использовать в дальнейшем (это, чтоб не выдумывать самому велосипед )
P>Да, нормальный известный пример. Но он больше касается automation, т.е. управлением извне UI и функциональностью приложения.
Почему-же? Достаточно взглянуть на Editor.Modules (из примера
). Здесь лежит как раз то, что Вам требуется относительно расширения конфигурации приложения.
P>Программировать под такую систему можно, но не очень удобно.
Тяжело сделать такой framework, а создавать расширения под него очень даже легко, если правильно спроектировать fw.
P>Куда девается RAD?
RAD как раз присутствует на уровне User Controls(*). Кто мешает их делать в IDE нормальными визуальными средствами? При создании формы мы добавляем несколько User Controls подряд — вот и решение, которое позволяет избавиться от закладок и всего остального (если надо), а необходимые поля начинают располагаться последовательно.
P>Мы уже не можем просто так визуально создать меню в design time.
Это не большая потеря, но и тут кое-что можно придумать.
P>Как быть опять же, если после года работы клиент решил доставить себе еще один модуль? (эволюция схемы, незаполненные новые параметры, накат модуля на кастомизированную базовую версию, обновления)...
Все можно сделать, как расширение базового. Описав конфигурационным файлом необходимые модули и модифицоровав БД можно получить нужный результат.
Здравствуйте, stasukas, Вы писали:
P>>Хорошо. Рассмотрим следующую ситуацию. У нас есть базовая конфигурация, miniBasis, к которой создаются модули CRM и WMS. Такие модули можно делать в виде plugin. Это будет касаться пользовательского интерфейса. Что насчет дополнительных полей в сущности Customer? S>Делаем новый класс, являющийся расширением Customer S>
S>public class CRMCustomer : Customer {...}
S>public class WMSCustomer : Customer {...}
S>
S>
Понятно. Вначале мне тоже казалось, что это идеальное решение .
Всё дело в том, что теперь в справочнике клиентов находится каша из различных наследников.
По идее, CRM модулю расширенная информация нужна для _всех_ клиентов. Так же, как и WMS.
По крайней мере есть ситуации, когда некий экземпляр Customer должен быть расширен до CRMCustomer и WMSCustomer одновременно.
Не, ок. Я понимаю, что WMSCustomer — это может быть не сама сущность, БО. Тогда у нас есть доп. таблицы в базе для расширений, каждый модуль работает с общим справочником так, как будто там только его кастомеры, т.е. БО делает для него прозрачным добавление полей и заполнение их default значениями.
Я спрашивал про сущности. Если посмотреть на эти таблицы расширений, то никакой диаграммы наследования для сущностей не будет. Будет так:
public class Customer {...}
public class CRMCustomerExt {...}
public class WMSCustomerExt {...}
S>
Типа так. Кстати, наследование реализации для БО тоже плохая идея, т.к. создаст много копий одних и тех же данных. Когда CRM и WMS работают одновременно, мы получим 3 копии: экземпляры Customer, CRMCustomer и WMSCustomer. Т.е. лучше юзать интерфейсы:
public interface ICustomer {...}
public interface ICRMCustomer {...}
public interface IWMSCustomer {...}
public class Customer : ICustomer {...}
public class CRMCustomer : ICRMCustomer
{
private ICustomer customer;
...
}
public class WMSCustomer : IWMSCustomer
{
private ICustomer customer;
...
}
S>
P>>Как добавить CRM возможности, чтобы ими было удобно пользоваться (а не через Advanced->CRM Options)? S>User Controls (см. далее по тексту*) P>>Как обеспечить интеграцию модулей, т.е. расширение фич WMS в присутствии модуля CRM? S>Описал выше, интерфейсную реализацию смотри ниже.
Здравствуйте, Poudy, Вы писали:
P>Понятно. Вначале мне тоже казалось, что это идеальное решение . P>Всё дело в том, что теперь в справочнике клиентов находится каша из различных наследников. P>По идее, CRM модулю расширенная информация нужна для _всех_ клиентов. Так же, как и WMS. P>По крайней мере есть ситуации, когда некий экземпляр Customer должен быть расширен до CRMCustomer и WMSCustomer одновременно.
P>Не, ок. Я понимаю, что WMSCustomer — это может быть не сама сущность, БО. Тогда у нас есть доп. таблицы в базе для расширений, каждый модуль работает с общим справочником так, как будто там только его кастомеры, т.е. БО делает для него прозрачным добавление полей и заполнение их default значениями.
P>Я спрашивал про сущности. Если посмотреть на эти таблицы расширений, то никакой диаграммы наследования для сущностей не будет.
Тут стоит определиться, как мы будем проектировать уровень бизнес-логики.
Понятно, что между интерфейсом и бизнес-логикой будут бегать DTO. Они совершенно спокойно могут быть расширениями, т.к. ничего кроме данных не передают. Проблема может заключаться в том, что в зависимости от дизайна уровня бизнес-логики необходимо разрабатывать свою технологию работы с Customer, CRMCustomer и WMSCustomer.
Я предлагаю сделать так: Определить структуру данных — таблица Customer имеет понятную структуру, CRMCustomer хранит связь с Customer и специфические расширения для сущности CRMCustomer, с WMSCustomer то же самое
Определить сервисы взаимодействия и хранения определенных ранее Customer, CRMCustomer и WMSCustomer
Для получения необходимых DTO можно делать агрегацию: для CRMCustomerDTO мы основную часть берем из сервиса Customer, а специфичную добавляем из CRMCustomer
Думаю, что такой вариант будет достаточно простым и эффективным. Одноврененная работа с разными сущностями в рамках предложенной технологии позволит выявить и разрешить конфликты совместной работы, а так же не таскать дубликаты в BLL.
P>Типа так. Кстати, наследование реализации для БО тоже плохая идея, т.к. создаст много копий одних и тех же данных. Когда CRM и WMS работают одновременно, мы получим 3 копии: экземпляры Customer, CRMCustomer и WMSCustomer. Т.е. лучше юзать интерфейсы: P>
Здравствуйте, stasukas, Вы писали: S>Я предлагаю сделать так: S> S>Определить структуру данных — таблица Customer имеет понятную структуру, CRMCustomer хранит связь с Customer и специфические расширения для сущности CRMCustomer, с WMSCustomer то же самое
ok. думаю, это очевидно наследования не нужно. и существенно не отличается от моего поста.
S>Определить сервисы взаимодействия и хранения определенных ранее Customer, CRMCustomer и WMSCustomer
Хорошо, но я не до конца понимаю, что там будет. Имеется в виду обычный аляMS DAL?
Мне кажется, имеет смысл говорить о расширяемых приложениях. с сервисами будут проблемы.
S>Для получения необходимых DTO можно делать агрегацию: для CRMCustomerDTO мы основную часть берем из сервиса Customer, а специфичную добавляем из CRMCustomer S>
ну ясно.
S>Думаю, что такой вариант будет достаточно простым и эффективным. Одноврененная работа с разными сущностями в рамках предложенной технологии позволит выявить и разрешить конфликты совместной работы, а так же не таскать дубликаты в BLL.
вот этого я совсем не понял. "одновременная работа с разными сущностями" "позволит выявить и рарешить" — это как?
S>На мой взгляд, это очень странная идея с интерфейсами...
Ну может быть. В принципе, ни наследование, ни интерфейсы, не обязательны.
Здравствуйте, Poudy, Вы писали:
S>>Я предлагаю сделать так: S>> S>>Определить структуру данных — таблица Customer имеет понятную структуру, CRMCustomer хранит связь с Customer и специфические расширения для сущности CRMCustomer, с WMSCustomer то же самое
P>ok. думаю, это очевидно наследования не нужно. и существенно не отличается от моего поста.
Возможно, но я предлагал сделать нечто напоминающее Class Table Inheritance (по Фаулеру). На уровне BLL все бегает относительно разрозненно (с некоторым "склеивающим" ID, чтоб агрегация работала), а собирается при переходе с уровня на уровень, т.е. с BLL на PL в DTO.
S>>Определить сервисы взаимодействия и хранения определенных ранее Customer, CRMCustomer и WMSCustomer
P>Хорошо, но я не до конца понимаю, что там будет. Имеется в виду обычный аляMS DAL?
Нет, не DAL. Именно набор бункциональности BLL.
P>Мне кажется, имеет смысл говорить о расширяемых приложениях. с сервисами будут проблемы.
Под сервисом я понимал некоторый набор операций, специфичный для сущности или группы сущностей, но никак не технологии. Кто мешает сделать некоторый набор таких сервисов (лучше их назвать бизнес-сервисами) и делать необходимые агрегирующие надстройки? Если есть необходимость отключить часть функциональности, то в агрегирующих сервисах мы можем сделать необходимую настройку или поставить dummy stub вместо этого сервиса.
S>>Для получения необходимых DTO можно делать агрегацию: для CRMCustomerDTO мы основную часть берем из сервиса Customer, а специфичную добавляем из CRMCustomer S>>
P>ну ясно.
S>>Думаю, что такой вариант будет достаточно простым и эффективным. Одноврененная работа с разными сущностями в рамках предложенной технологии позволит выявить и разрешить конфликты совместной работы, а так же не таскать дубликаты в BLL.
P>вот этого я совсем не понял. "одновременная работа с разными сущностями" "позволит выявить и разрешить" — это как?
Мы всегда можем сделать любой из видов блокировки в своем приложении на уровне сущностей или специфических свойств сущностей (т.е. как бы на уровне представления таблицами). Таким образом мы можем независимо работать с разными сущностями при редактировании различных данных (относязихся к различным сущностям), но и сможем разрешать конфликты при изменении одних и тех же данных.
Например, один пользователь редактирует Customer, а другой CRMCustomer. При этом, если изменения не пересекаются по сущностям, то конфликта нет, а если пересечение есть (изменения в Customer), то возникает конфликт, который мы решаем стандартным выбранным образом.
У меня такое видение данной проблемы. Если кто-нибудь видит ее по другому, то я рад был бы выслушать и других.
Если есть желание, то могу объяснить более подробно на ближайшей RSDN UG или MDNA UG в Москве.
Здравствуйте, stasukas, Вы писали: S>Под сервисом я понимал некоторый набор операций, специфичный для сущности или группы сущностей, но никак не технологии. Кто мешает сделать некоторый набор таких сервисов (лучше их назвать бизнес-сервисами) и делать необходимые агрегирующие надстройки? Если есть необходимость отключить часть функциональности, то в агрегирующих сервисах мы можем сделать необходимую настройку или поставить dummy stub вместо этого сервиса. S>
Понятно. С другой стороны, не вижу леса за деревьями. Честно говоря, не вполне понятно, какое отношение модель клиент-серверного взаимодействия и aggregation layer имеет к вопросу проектирования бизнес-модели.
Я обдумывал архитектуру конфигурируемой erp, в которой есть базовая часть, специализированные модули и пользовательская конфигурация. И видел в этом две проблемы, которые нужно решить, чтобы все было хорошо:
1. разработка модулей — т.е. как модулей, а не как отдельных различных конфигураций одной системы.
2. накат новых версий базовой конфигурации и модулей так, чтобы не страдала клиентская конфигурация. сейчас ни 1C, ни Axapt'у, ни SAP нельзя кастомизировать не попортив базовую версию. накатить после этого расширения функциональности от поставщика очень сложно. т.е. можно поставить новую version 4.2.1.13, но нельзя обновить покуроченную конфигурацию CRM Solutions 9 на CRM Solutions 10.
IMHO, собственно это и есть вопрос проектирования сущностей, их представлений и обработки событий.
P>>вот этого я совсем не понял. "одновременная работа с разными сущностями" "позволит выявить и разрешить" — это как? S>Мы всегда можем сделать любой из видов блокировки в своем приложении на уровне сущностей или специфических свойств сущностей (т.е. как бы на уровне представления таблицами). Таким образом мы можем независимо работать с разными сущностями при редактировании различных данных (относязихся к различным сущностям), но и сможем разрешать конфликты при изменении одних и тех же данных. S>Например, один пользователь редактирует Customer, а другой CRMCustomer. При этом, если изменения не пересекаются по сущностям, то конфликта нет, а если пересечение есть (изменения в Customer), то возникает конфликт, который мы решаем стандартным выбранным образом.
понятно. в принципе, да, можем. просто я пока сторонник offline решений. хотя я все время работал над online системами, я всё время обдумываю, как бы сделать всё offline.
S>У меня такое видение данной проблемы. Если кто-нибудь видит ее по другому, то я рад был бы выслушать и других. S>Если есть желание, то могу объяснить более подробно на ближайшей RSDN UG или MDNA UG в Москве.
желание есть.
Здравствуйте, Poudy, Вы писали:
P>Понятно. С другой стороны, не вижу леса за деревьями. Честно говоря, не вполне понятно, какое отношение модель клиент-серверного взаимодействия и aggregation layer имеет к вопросу проектирования бизнес-модели.
Возможно, что я сильно завяз в xml, поэтому для меня не вызывает особой проблемы обеспечение передачи относительно разнородных данных одним пакетом. В этом и есть та гибкость, которая необходима при общении PL и BLL. А отсюда вытекает и расширяемость.
P>Я обдумывал архитектуру конфигурируемой erp, в которой есть базовая часть, специализированные модули и пользовательская конфигурация. И видел в этом две проблемы, которые нужно решить, чтобы все было хорошо: P>1. разработка модулей — т.е. как модулей, а не как отдельных различных конфигураций одной системы.
Пожалуйста — относительно независимые бизнес-сервисы. общая конфигурация системы
P>2. накат новых версий базовой конфигурации и модулей так, чтобы не страдала клиентская конфигурация. сейчас ни 1C, ни Axapt'у, ни SAP нельзя кастомизировать не попортив базовую версию. накатить после этого расширения функциональности от поставщика очень сложно. т.е. можно поставить новую version 4.2.1.13, но нельзя обновить покуроченную конфигурацию CRM Solutions 9 на CRM Solutions 10.
Почему нельзя расширять конфигурацию таких систем? Строго определенные DTO, которые не могут независимо изменять структуру. Если передавать сущности с помощью xml, то не будет возникать проблем с расширением функциональности каждого бизнес-сервиса.
P>IMHO, собственно это и есть вопрос проектирования сущностей, их представлений и обработки событий.
Здравствуйте, stasukas, Вы писали:
S>Возможно, что я сильно завяз в xml, поэтому для меня не вызывает особой проблемы обеспечение передачи относительно разнородных данных одним пакетом. В этом и есть та гибкость, которая необходима при общении PL и BLL. А отсюда вытекает и расширяемость.
Я сам передаю данные в xml. Он хорош. Вопрос — при чем тут xml? Aggregation можно сделать как угодно, но не все же задачи сводятся к передаче данных Я сейчас не смотрю ни на таблицы, ни на DataSet, ни вообще на DTO. Оставим за рамками aggregation level. Вопрос в том, как расширять сущности.
Возьмем 1С:
Клиент запускает конфигуратор и добавляет новые атрибуты к справочникам. пишет код. после этого накатить обновления конфигурации проблематично.
Возьмем SAP:
Нужно добавить флажок к единице учета. Клиент берет поле Reserved1 в таблице и юзает под себя. Потому что заводить новую колонку нехорошо — может быть конфликт имен.
Мне кажется, что можно решить такую проблему, если делать следующие вещи:
— любые расширения сущностей делаются как создание новой сущности, агрегирующей старую. это мы уже обсудили. контроль доступа и прочее делается на уровне каждой из сущностей своими службами. Рассмотрим модуль CRM. Он расширил Customer полями Debt и прочее. Вроде как теперь во всех используемых сущностях должен быть CRMCustomer. Принципиально никто не мешает нам нагенерить заново все классы БО, чтобы они работали с CRMCustomer. Иногда нужно из модуля CRM нужно работать с WMSCustomer. Этого WMSCustomer также можно сгенерить специально под модуль CRM, вроде как proxy. Теперь можно будет спокойно апдейтить базовую конфигурацию. Старый CRM просто не будет знать о новых сущностях, полях и методах. Если мы не используем наследвоание, references и т.д., то проблем нет.
Просто это означает, что если кто-то захочет покопаться в CRM, для него нужно отпачковать еще одну версию всех сущностей. Тогда можно будет апдейтить и CRM модуль тоже. думаю так.
P>>Я обдумывал архитектуру конфигурируемой erp, в которой есть базовая часть, специализированные модули и пользовательская конфигурация. И видел в этом две проблемы, которые нужно решить, чтобы все было хорошо: P>>1. разработка модулей — т.е. как модулей, а не как отдельных различных конфигураций одной системы. S>Пожалуйста — относительно независимые бизнес-сервисы. общая конфигурация системы
да, почти так.
S>Почему нельзя расширять конфигурацию таких систем? Строго определенные DTO, которые не могут независимо изменять структуру. Если передавать сущности с помощью xml, то не будет возникать проблем с расширением функциональности каждого бизнес-сервиса.
не только поэтому. см. выше, а кроме того есть еще методы и формочки. кто-то залазит в код метода и меняет его. двигает на формочке контролы и меняет их цвет.
Здравствуйте, 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 модуль тоже. думаю так.
Из всего сказанного по теме я сделал вывод, что можно работать двумя способами в данной ситуации: Работаем с бизнес-сервисами, которые оперируют своими "обрезками" от сущности, логическая склейка происходит за счет интерфейса пользователя. Преимущества этого подхода заключаются в отсутствии какого-либо пересечения между модулями системы. Минусы —
Работаем с xml и агрегаторами, которые должны уметь склеивать в единую сущность все данные по расширению всех используемых сущностей, а на уровне интерфейса мы должны расклеивать для каждого модуля. Тут плюсы очевидны — есть композитная сущность, из которой каждый модуль может вытянуть необходимую ему часть, а при расширении системы мы изменяем тем или иным способом агрегаторы. Из минусов следует отметить, что мы используем упаковку/распаковку и таскаем сущности полностью, а это повышает сложность системы.
На мой взгляд, первый вариант предпочтительнее использовать. Ну а склейку модулей в интерфейсной части мы обсуждали.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Now playing: Armin van Buuren — Armin van Buuren — A State Of Trance 001 CD2
Здравствуйте, stasukas, Вы писали:
P>>Мне кажется, что можно решить такую проблему, если делать следующие вещи: P>>- любые расширения сущностей делаются как создание новой сущности, агрегирующей старую. это мы уже обсудили. контроль доступа и прочее делается на уровне каждой из сущностей своими службами. Рассмотрим модуль CRM. Он расширил Customer полями Debt и прочее. Вроде как теперь во всех используемых сущностях должен быть CRMCustomer. Принципиально никто не мешает нам нагенерить заново все классы БО, чтобы они работали с CRMCustomer. P>>Иногда нужно из модуля CRM нужно работать с WMSCustomer.
S>А это не ошибка проектирования? Тогда получается, что подсистемы теряют независимость.
нет, это требования функциональности. у пользователя может и не быть модуля WMS. но если бизнес-логика системы такая, что модули могут и должны использовать друг друга? т.е. я имел в виду именно случай, если поставив оба модуля мы получим дополнительную функциональность в каждом. если нам так захотелось. если так захотелось клиентам.
S>Из всего сказанного по теме я сделал вывод, что можно работать двумя способами в данной ситуации: S> S>Работаем с бизнес-сервисами, которые оперируют своими "обрезками" от сущности, логическая склейка происходит за счет интерфейса пользователя. Преимущества этого подхода заключаются в отсутствии какого-либо пересечения между модулями системы. Минусы — S>
S>Работаем с xml и агрегаторами, которые должны уметь склеивать в единую сущность все данные по расширению всех используемых сущностей, а на уровне интерфейса мы должны расклеивать для каждого модуля. Тут плюсы очевидны — есть композитная сущность, из которой каждый модуль может вытянуть необходимую ему часть, а при расширении системы мы изменяем тем или иным способом агрегаторы. Из минусов следует отметить, что мы используем упаковку/распаковку и таскаем сущности полностью, а это повышает сложность системы. S> S>S>На мой взгляд, первый вариант предпочтительнее использовать. Ну а склейку модулей в интерфейсной части мы обсуждали.
я не вижу существенной разницы. по мне, все отличие указанных способов только в том, как данные ходят от клиента: "обрезками" или вместе.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, stasukas, Вы писали:
P>>>Мне кажется, что можно решить такую проблему, если делать следующие вещи: P>>>- любые расширения сущностей делаются как создание новой сущности, агрегирующей старую. это мы уже обсудили. контроль доступа и прочее делается на уровне каждой из сущностей своими службами. Рассмотрим модуль CRM. Он расширил Customer полями Debt и прочее. Вроде как теперь во всех используемых сущностях должен быть CRMCustomer. Принципиально никто не мешает нам нагенерить заново все классы БО, чтобы они работали с CRMCustomer. P>>>Иногда нужно из модуля CRM нужно работать с WMSCustomer.
S>>А это не ошибка проектирования? Тогда получается, что подсистемы теряют независимость.
P>нет, это требования функциональности. у пользователя может и не быть модуля WMS. но если бизнес-логика системы такая, что модули могут и должны использовать друг друга? т.е. я имел в виду именно случай, если поставив оба модуля мы получим дополнительную функциональность в каждом. если нам так захотелось. если так захотелось клиентам.
Может логичнее было бы все-таки делать независимые модули, а пересечение функциональности выносить в отдельный модуль.
P>я не вижу существенной разницы. по мне, все отличие указанных способов только в том, как данные ходят от клиента: "обрезками" или вместе.
Да, именно об этом я и говорил.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Now playing: Paul Oakenfold — Zoo York
Здравствуйте, stasukas, Вы писали:
S>>>А это не ошибка проектирования? Тогда получается, что подсистемы теряют независимость. P>>нет, это требования функциональности. у пользователя может и не быть модуля WMS. но если бизнес-логика системы такая, что модули могут и должны использовать друг друга? т.е. я имел в виду именно случай, если поставив оба модуля мы получим дополнительную функциональность в каждом. если нам так захотелось. если так захотелось клиентам.
S>Может логичнее было бы все-таки делать независимые модули, а пересечение функциональности выносить в отдельный модуль.
Может быть. просто мне кажется, что сделать так будет непросто.
P>>я не вижу существенной разницы. по мне, все отличие указанных способов только в том, как данные ходят от клиента: "обрезками" или вместе. S>Да, именно об этом я и говорил.
Здравствуйте, Poudy, Вы писали:
S>>Может логичнее было бы все-таки делать независимые модули, а пересечение функциональности выносить в отдельный модуль. P>Может быть. просто мне кажется, что сделать так будет непросто.
При проявлении такой связанности (tight coupled) сразу начинают возникать проблемы с модульностью.
P>>>я не вижу существенной разницы. по мне, все отличие указанных способов только в том, как данные ходят от клиента: "обрезками" или вместе. S>>Да, именно об этом я и говорил.
P>ок. а что по поводу самих модулей?
Помоему, ранее мы это обсуждали (с точки зрения интерфейсной части). Если речь идет о БЛ, то все зависит от реализации
. В первом случае мы прописыаем конфигурацию для каждого модуля, куда ему обращаться. Во втором — агрегатор БЛ должен понимать, какие модули подключены.
Здравствуйте, stasukas, Вы писали:
S>>>Может логичнее было бы все-таки делать независимые модули, а пересечение функциональности выносить в отдельный модуль. P>>Может быть. просто мне кажется, что сделать так будет непросто. S>При проявлении такой связанности (tight coupled) сразу начинают возникать проблемы с модульностью.
безусловно. я только отметил, что иногда такое может понадобиться.
P>>ок. а что по поводу самих модулей?
S>Помоему, ранее мы это обсуждали (с точки зрения интерфейсной части). Если речь идет о БЛ, то все зависит от реализации
. В первом случае мы прописыаем конфигурацию для каждого модуля, куда ему обращаться. Во втором — агрегатор БЛ должен понимать, какие модули подключены.
конечно. но это все теория. насколько такой "автоматически" подход окажется жизнеспособным? я имею в виду ugly GUI, плохая логика работы с формами и пр.
Здравствуйте, Poudy, Вы писали:
P>конечно. но это все теория. насколько такой "автоматически" подход окажется жизнеспособным? я имею в виду ugly GUI, плохая логика работы с формами и пр. Эксперименты покажут. Жаль, вот только никто из профи в этой области не отозвался со своим мнением в данной области (за исключеним минуса в мою сторону от Mishka). Может и нет у нас таких?
Ладно, при встрече можно будет обсудить это более подробно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Now playing: Tsunami One CD1 mixed by Ferry Corsten
Здравствуйте, stasukas, Вы писали:
S>Здравствуйте, Poudy, Вы писали:
S>>>Может логичнее было бы все-таки делать независимые модули, а пересечение функциональности выносить в отдельный модуль. P>>Может быть. просто мне кажется, что сделать так будет непросто. S>При проявлении такой связанности (tight coupled) сразу начинают возникать проблемы с модульностью.
P>>>>я не вижу существенной разницы. по мне, все отличие указанных способов только в том, как данные ходят от клиента: "обрезками" или вместе. S>>>Да, именно об этом я и говорил.
P>>ок. а что по поводу самих модулей?
S>Помоему, ранее мы это обсуждали (с точки зрения интерфейсной части). Если речь идет о БЛ, то все зависит от реализации
. В первом случае мы прописыаем конфигурацию для каждого модуля, куда ему обращаться. Во втором — агрегатор БЛ должен понимать, какие модули подключены.
Как насчет делать тем же образом как система плугинов OUTLOOK?
Плугин сам регистрируется в системе при старте, вешается на события, прописывает себя в коллекциях контролов и т.п.,
При необходимости при введении нового плугина расширять функционал остальных плугинов — аналогично в этом же плугине или
В плугине надстройке над остальными плугинами пишется функциональность.
Связь с базой — аналогично — запросы — расширяемые объекты. Т.е. Плугин, навешиваясь "подмешивает" в запросы к бд
свои элементы.
Единственная беда — layout manager делать прийдется (для гуя).
Здравствуйте, madrogue, Вы писали:
M>Как насчет делать тем же образом как система плугинов OUTLOOK? M>Плугин сам регистрируется в системе при старте, вешается на события, прописывает себя в коллекциях контролов и т.п., M>При необходимости при введении нового плугина расширять функционал остальных плугинов — аналогично в этом же плугине или M>В плугине надстройке над остальными плугинами пишется функциональность.
Если внимательно почитать тему с начала, то именно такой способ я и предлагал.
M>Связь с базой — аналогично — запросы — расширяемые объекты. Т.е. Плугин, навешиваясь "подмешивает" в запросы к бд M>свои элементы.
Запросы в Presentation Layer? Я думал, что так уже никто не делает...
M>Единственная беда — layout manager делать прийдется (для гуя).
Тут необходимо думать не только над Presentation Layer, но и над Business Logic Layer или Workflow Logic Layer, т.е. над их взаимодействием.
[tagline]... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Now playing: Zakhm — Insaan ][/tagline
)
.
Жаль, вот только никто из профи в этой области не отозвался со своим мнением в данной области (за исключеним минуса в мою сторону от Mishka). Может и нет у нас таких? 
Я думал, что так уже никто не делает... 
