Справка по дизайну - объект изменяет и сохраняет другой объект

Question

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

Вот сценарий:

У меня есть класс Employee, у которого класс сотрудника есть список объектов Office (где сотрудник работает и работал). У меня есть требование создать возможность переводить сотрудника между офисами. Существуют дополнительные издержки для запроса на перенос (Утверждения, Обзоры), но в конце утверждения мой объект переноса должен привести к изменению Списка офисов объектов сотрудников.

Я использую C #, EF4 и POCO для своих объектов. Я не уверен, как смоделировать объект переноса. Это будет сохраняться в течение некоторого времени и может не быть завершено в течение нескольких дней (согласования должны быть завершены до того, как будет разрешено продолжить). Передающий объект должен знать сотрудника для изменения и новый офис для сотрудника. Я чувствую, что это плохой дизайн - делать Employee дочерним объектом объекта Transfer и модифицировать его там. Мне просто интересно, есть ли у кого-нибудь совет, как смоделировать это требование.

Answer 1

Вы можете рассматривать перевод как совершенно отдельный объект - EmployeeTransfer.

Как минимум, он будет содержать следующие данные: 1. Уникальный идентификатор Сотрудника.2. Уникальный идентификатор перевода из офиса.3. Уникальный идентификатор перевода в офис.4. Индикатор состояния для выполнения передачи.

Это легкий объект, который не содержит никаких других объектов - он ссылается на них по уникальному идентификатору.Когда передача обработана, проверьте, что офис «Сотрудник» и «Перевод в офис» все еще действительны, а затем обновите коллекцию «Офисы сотрудников».

Единственным предварительным условием для этого решения является наличие сотрудника и офисов до созданияпередачи.

Answer 2

Если вы думаете об ответственности объекта Transfer, это управление перемещением сотрудника в другой офис.Я бы разработал это так, чтобы объект Transfer был отделен от Employee и Office, но имел ссылку на каждого из них.Объект Transfer, вероятно, будет иметь значения состояния Enum of Approval, и по достижении конечного состояния (отмененное или окончательное утверждение) объект Transfer может выполнить действие по связыванию Employee с новым Office и пометить себя как выполненное.Это не плохой дизайн для объекта Transfer, чтобы иметь ссылки на другие объекты.Отношения между Transfer и Employee (а также Transfer и Office) в этом случае являются отношениями «использует».

Answer 3

Звучит так, будто Transfer - это не объект, а рабочий процесс.Посмотрите на Windows Workflow Foundation ... Вот хороший пример быстрого запуска .