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

Question

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

Имеется три варианта, например, для обновления информации об участнике. Как нам оформить контракт?

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

Подробности:

• Номера телефонов,
• Адрес,
• E-mail
• Название или название компании,
• Контактное лицо,
• Номер налогового досье,
• Семейное положение
• Статус курильщика

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

Вариант 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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

Answer 3

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

«Интуитивно» может быть лучшим словом для подражания - что вам подходит?

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

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