Детализация запроса на обновление SOA и значения NULL

Question

Мы стремимся к созданию SOA...

Учитывая три варианта, скажем, обновление информации об участнике, как мы оформляем контракт?

Бизнес-процесс довольно прост. Клиент звонит (или входит в систему) и обновляет свои личные данные, чтобы мы могли получать самые последние данные. Заказчик также может предоставить данные о членах (это будет массово - потенциально 10 тысяч из 1000 за раз). Это так, чтобы мы могли правильно общаться с ними в будущем. У нас есть несколько внутренних систем.

Детали:

• Телефонные номера,
• Адреса,
• Эл. адрес,
• Имя или название компании,
• Контактное лицо,
• Номер налоговой декларации,
• Семейное положение
• Статус курильщика

В настоящее время применяются следующие бизнес-правила: если действительный номер налогового файла уже был предоставлен, вы не можете предоставить его снова. (может быть переопределено). При наличии действительных данных об адресе работодатель не может их обновить, а указывает только в первый раз.

Вариант 1: одна операция, Member.UpdateDetails

• Только один сервис для создания и управления.
• Если бизнес-правила растут, эта услуга может стать менее сплоченной.
• Имеет проблему разграничения между указанием, что что-то должно быть удалено, и тем, чтобы оставить это как есть
• Одна единица работы, одна транзакция.

Вариант 2: разбить на четыре операции: Member.UpdateContactDetails; Member.ProvideTaxFileNumber; Member.UpdateName; Member.UpdateDemographics

• Потенциально упрощает одну операцию - распределяет сложность по четырем операциям.
• По-прежнему существует проблема разграничения между указанием, что что-то должно быть удалено, и тем, чтобы оставить это как есть. Например, что, если бы я только хотел указать статус курильщика без семейного положения.
• Требуется некоторый глубокий анализ, чтобы выяснить, как правильно их сгруппировать - взаимосвязанность зависит от бизнес-процесса.
• Больше сервисов для написания и поддержки.
• Транзакции становятся проблемой - несколько транзакций обрабатываются вызывающей стороной?

Вариант 3: разбить на еще меньше: Member.UpdateAddress; Member.UpdateBusinessDetails; Member.UpdateContactNumbers; Member.UpdateContactPerson; Member.UpdateEmailAddress; Member.UpdateMailingAddress; Member.UpdatePhysicalAddress; и т.п.

• Устраняет проблему необходимости проводить различие между указанием, что что-то должно быть удалено, и тем, чтобы оставить это как есть.
• Бизнес-правила могут легко развиваться в любой операции.
• Множество сервисов для написания и поддержки.
• Транзакции становятся проблемой - многие транзакции обрабатываются вызывающей стороной?
• Начните выглядеть как установщики свойств / CRUD - видимо, нет.

В первом или втором варианте, скажем, вызывающий абонент хочет обновить только домашний адрес электронной почты - я не могу ожидать, что клиент завершит все сообщение - клиент пропускает все остальные теги? Каков принятый, очевидный, интуитивный образец для решения этой проблемы?

Если это действительно шаблон, то как клиент очищает поле или устанавливает его в ноль? В.NET, в коде сервера я не вижу очевидного способа различения между непредоставленным и нулевым. Поскольку это не очевидно, я ожидаю, что это не принятый образец.

Answer 1

Используйте грубозернистый API с мелкозернистыми аргументами. Если вы не хотите, чтобы поле обновлялось, передайте дескриптор, сообщающий это вместе с данными. Что-то вроде:

Result updateMember(Member member, List<String> fieldsToUpdate)

Наличие мелкозернистого API - в основном смерть, потому что транспорт часто скрыт.

Если кто-то пишет:

UpdateContactNumbers(...);
UpdateAddress(...);
UpdatePersonalDetails(...);

Скорее всего, они только что совершили а) 3 поездки по сети вместе с б) 3 поездками в БД, завершение с) 3 транзакциями в БД. Это не учитывает все пристрастное и неумолимое веселье.

Что, конечно, безумие.

Требуется ли удаленный API службы? Нет, конечно нет, но многие из них, и, как минимум, многие прозрачны для транспорта (могут быть локальными или удаленными, вы не знаете).

Так. Грубый API, мелкозернистые аргументы. Выясните, что вы хотите сделать, подробно, и сделайте все это за один раз.

Answer 2

Я настоятельно рекомендую второй вариант, потому что он сохраняет намерение пользователя вносить изменения в код, который на него воздействует.

Первое преимущество заключается в том, что он освобождает вас от ответа на вопрос "как я могу представить удаление в DTO" - потому что теперь вы бы восприняли этот факт как DeleteContactNumber сообщение, явно.

Второе преимущество заключается в том, что вы свободны, отвечая на вопрос "как добавить несколько адресов одновременно" - поскольку вам не нужно делать вывод, что кто-то добавил адрес из мутировавшего DTO, вы получаете AddContactAddress сообщение.

Третье преимущество заключается в том, что вы можете сделать более интересный бизнес-анализ в конце дня - потому что вы знаете, что происходит, без необходимости анализировать DTO и делать выводы.

Наконец, становится проще добавлять больше информации к конкретным событиям: хотите ли вы знать, почему люди удаляют свой контактный адрес?

Использование модели "выборка данных, изменение данных, сохранение данных" - это не столько строчки кода, но в конечном итоге усложняет понимание того, почему в вашей системе что-то происходит, и это в конечном итоге будет стоить вам.

Answer 3

Лично я не вижу слишком много неправильных в наличии возможности UpdateMember и более простых возможностей UpdateAddress и т. Д. Некоторые могут поспорить, но я думаю, что это будет вполне приемлемо.

Слово "интуитивный" может быть лучшим словом для подражания - что вам кажется правильным?

Мне кажется, что UpdateMember определенно подходит для включения. Если этот сервис используется пользовательским интерфейсом, все поля, вероятно, уже будут заполнены вызовом GetMember, поэтому все поля будут заполнены в любом случае их исходными значениями. Вы могли бы использовать что-то подобное, даже если это не пользовательский интерфейс. Затем вы можете иметь UpdateAddress, Update PersonalDetails, а также, для более простых, специализированных обстоятельств.

Однако мне не нравится эта идея - иметь возможность только UpdateMember и оставлять поля, которые вы не хотите менять, пустыми. Я не думаю, что многие люди используют этот шаблон, и я, конечно, не буду. Как вы говорите, как вы тогда установите поле в нуль.