Разработка CRM - ранний подход, поддерживающий несколько организаций
Мы сталкиваемся с проблемой, когда хотим разработать библиотеку CRM (менеджер) на C#, которая будет поддерживать связь с несколькими системами CRM, т. Е. Ситуация, когда вы запускаете более одного экземпляра CRM одновременно (например, две разные организации).).
Требования к библиотеке CRM:
Используйте раннее связывание вместо позднего (из-за безопасности типов)
Возможность общаться с несколькими CRM-системами (организациями) через одного менеджера
Только один метод для одной операции (избегайте дублирования кода) используется для всех систем CRM (организаций) - необходимо будет создать утилиту для анализа сгенерированных файлов сущностей (инструмент crmsvcutil) для каждой организации. Результатом анализа будет список интерфейсов и частичных классов для сущностей, определенных в файлах сущностей. Интерфейсы будут реализованы в частичных классах в соответствии с атрибутами, которые они содержат, например, IAccountNumber и т. Д. Будет две группы интерфейсов - первая для атрибутов сущности, общих для обеих организаций, например, интерфейс ICrmAccount будет определять атрибуты AccountNumber, Name, Address1 и т. Д. Вторая группа интерфейсов будет для атрибутов, которые являются уникальными для сущности и не присутствуют в сущности ВСЕХ CRM-систем (организаций). Затем общий диспетчер CRM предложит все методы связи, такие как CreateAccount(), GetAccount() и т. Д., Которые затем будут работать с конкретной системой CRM благодаря реализованным интерфейсам.
Мы разработали решение, которое теперь способно взаимодействовать с двумя различными системами CRM, но не может использовать реализованные интерфейсы для конкретной учетной записи, см. Прилагаемое решение, которое содержит комментарии к коду.
Решение можно найти здесь:
Описание решения:
CRM_BusinessLogic - содержит CRMManager, который содержит все методы для связи и инициализирует правильный контекст данных в конструкторе
CRM_Interfaces - содержит все сгенерированные интерфейсы, которые являются результатом анализа файлов сущностей (это должно быть сделано с помощью отдельного инструмента синтаксического анализа). Теперь содержит только iCRMAccount, содержащий только один общий атрибут для обеих организаций, и iCRMContext, который содержит сущность, реализованную в обоих контекстах данных - теперь в обоих контекстах реализована одна и та же сущность Account.
CRM_SCEurope - содержит сгенерированный файл сущностей для первой организации CRM SC Europe - SCEuropeEntities.cs, сгенерированный контекст данных инструментом синтаксического анализа (реализует список интерфейса, в соответствии с которым сущности присутствуют в контексте организации) - SCEuropeContext_generated и SCEuropeContext.cs, который возвращает правильный сборка
CRM_SoSW - тот же контент, что и CRM_SCEurope, содержит данные, относящиеся ко второй организации CRM
CRM_Test - содержит тестовое консольное приложение, которое будет взаимодействовать с обеими организациями
Обратите внимание, что прилагаемое решение содержит только сущность Account с единственным параметром Name, которого достаточно для базового тестирования разработанного решения.
Важно: перед запуском проекта необходимо установить учетные данные для менеджера в файле Program.cs (проект CRM_Test).
Как вы можете видеть, загружаются ли данные Пользователя из CRM с использованием сгенерированных частичных классов (SoSwContext,SCEuropeContext) с реализованным интерфейсом iCRMContext, приложение выдает исключение "Недопустимое условие" где ". Член сущности вызывает недопустимое свойство или метод". - см. реализацию метода.
Мы будем признательны, если кто-нибудь найдет решение, как решить исключение.
Спасибо
Павел
1 ответ
Для моего нынешнего работодателя у них есть несколько CRM-организаций, некоторые из них почти идентичны, и мы на самом деле можем использовать точно такие же классы с ранним связыванием с 20 строками пользовательского кода для обработки различий. Других организаций нет, и поэтому у нас есть отдельная dll с пространством имен, специфичным для организации, содержащим сгенерированные ранние связанные типы. Нет причины, по которой они не могли бы находиться в одной и той же dll, но у вас возникнут проблемы, если они все будут в одном и том же пространстве имен, поскольку каждый из них определит свое собственное определение для контакта, встречи и т. Д.
Просто помните, что вы можете использовать ранние связанные типы для другой организации, если вы не пытаетесь выбрать или обновить определенное поле или объект, который не существует. Поэтому, если у Org 1 есть CompanyId в объекте Contact, а у Org 2 нет, вы все равно можете использовать ранние типы привязки для Org 1, для Org 2, если вы не заполнили CompanyId (т.е. поместите его в коллекция параметров объекта)