WCF - Определение параметров проектирования - PullRequest
Новая
       6

WCF - Определение параметров проектирования

1 голос
/ 04 марта 2012

Я разрабатываю сервис для FundManagement. Служба управления фондом имеет операцию с именем «UpdateFundApprovalDate (фонд FundDTO)». Эта операция обновит запись таблицы фонда с датой утверждения дляndingID. Услуга будет использоваться клиентом «FundManagementUI».

Существует бизнес-правило, согласно которому дата утверждения не должна обновляться, если продление контракта выполняется.

Существует отдельная служба продления. Служба обновления использует данные из таблицы обновления (в которой есть идентификатор финансирования). Структура таблицы обновления (RenewalID, FundingID, RenewalStartDate, Renewal CompletionDate, RenewalStatus). Существует сервисная операция под названием «публичный список GetInProgressRenewal (фонд FundDTO)».

Один важный момент здесь. Хотя обе службы используют одну и ту же базу данных, обновление «В процессе» должно решаться службой обновления. Это может быть основано на статусе или дате завершения записи обновления. Служба продления должна решать бизнес-логику продлений в процессе. Служба управления фондом не претендует на владение этой логикой.

  1. Каков принцип / шаблон SOA, объясняющий вышеуказанное поведение? (Использование службы продления для определения продлений «в процессе», хотя существует риск, что служба продления может изменить логику в своих интересах.). Каковы рекомендации по таким сценариям?

  2. Есть ли у вас какие-либо предложения для каких-либо статей, касающихся таких решений?

  3. В Службе управления фондом, кто должен отвечать за проверку того, что список возвращенных обновлений равен NULL? Где эта проверка должна происходить внутри кода метода работы службы или внутри FundBusinessLayer (который вызывает служба)?

Примечание. Здесь SOA будет реализована с использованием WCF, а бизнес-класс будет разработан с использованием C #.

ЧТЕНИЕ:

  1. SOA / WCF, разделяющие границы системы и сервиса

Ответы [ 2 ]

4 голосов
/ 04 марта 2012

В этом случае я бы не использовал существующие службы в службе обновления, как вы говорите, они могут измениться.

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

Поэтому я бы создал новую операцию: IsContractRenewalInProgress .Это устраняет необходимость думать о том, кто должен нести ответственность за проверку того, что возвращенный список обновлений имеет значение NULL.Более важно то, что список, имеющий значение NULL, означает, что продление контрактов не выполняется.

UpdateFundApprovalDate будет вызывать и проверять результат IsContractRenewalInProgress , прежде чем вносить какие-либо изменения.

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

1 голос
/ 23 апреля 2013

Любая обработка финансовой информации будет вращаться вокруг одного ключевого аспекта - тщательного управления статусом.

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

Вы можете обнаружить, что вам будет легче, если вы детализируете свои состояния, чтобы отразить текущую обработку - то есть вместо того, чтобы REVIEWED, RENEWED, APPROVED, REJECTED, FUNDED, также имеют состояния, которые установлены, чтобы указать, что контракт находится в состояние потока - то есть он сейчас пересматривается, сейчас финансируется и т. д. Таким образом, система может идентифицировать контракты, которые сейчас активно обрабатываются. Это также позволяет легко определить, что происходило в случае внезапного сбоя среды без успешного отката.

Убедитесь, что у вас есть только одна служба, которая обновляет состояние контракта, и что эта служба блокирует контракт во время обновления. Все остальные процессы будут использовать эту службу для выполнения необходимых изменений статуса.

Таким образом, в вашем конкретном случае UpdateFundApprovalDate (фонд FundDTO) будет запускаться только для контрактов, статус которых был PENDING_FUNDING, и, вероятно, будет только частью общей обработки - в любом случае, когда процесс, выполняющий ваше updateFundApprovalDate (Фонд FundDTO) завершается, статус контракта будет либо ФИНАНСИРОВАН, если он был успешным, либо, если попытка финансирования не удалась, все изменения будут отменены, что приведет к исходному статусу контракта PENDING_FUNDING. Если система выйдет из строя, статус контракта может быть потенциально оставлен в текущем состоянии обработки, имеющем состояние, похожее на FUNDING. Само ФИНАНСИРОВАНИЕ не будет действительным состоянием в вашей модели состояний - это промежуточное состояние. Все процессы начнут обрабатывать контракт только в действительном состоянии, а не в промежуточных.

Для шаблонов, которые могут использоваться в этой ситуации, посмотрите шаблоны State Machine.

...