Design Help - Object modifies and saves another Object

I am having some troubles thinking through a design issue and thought that the community may be able to help point me in the right direction. I am modeling an employee management system for my company and have come to a design question that has me stumped.

Here is the scenario:

I have an Employee class that employee class has a list of Office objects (where the employee works and has worked). I have a requirement to create the ability to transfer an employee between offices. There is some extra overhead for the transfer request (Approvals, Reviews) but at the end the approvals my transfer object should cause the Employee Object Office List to be changed.

I am using C#, EF4 and POCO for my objects. I am not sure how to model the transfer object. It is going to be persisted for some time and may not be completed for a few days (approvals have to complete before its allowed to continue). The transfer object needs to know the employee to modify and the new office for the employee. I feel like it is bad design to make the Employee a child of the Transfer object and modify it there. I am just wondering if anyone has any advice on how to model this requirement.

You could treat the transfer as a completely separate object - an EmployeeTransfer.

As a minimum, it would contain the following data: 1. The unique identifier of an Employee. 2. The unique identifier of a Transfer From Office. 3. The unique identifier of a Transfer To Office. 4. A Status indicator for the progress of the Transfer.

This is a lightweight object that does not contain any other objects - it references them by unique identifier. When the Transfer is processed, validate that the Employee and Transfer To offices are still valid, then update the Employee Offices collection.

The only prerequisite for this solution is that the Employee and the Offices must exist prior to the creation of the Transfer.

It sounds like Transfer isn't an object, it's a workflow. Look at Windows Workflow Foundation... Here's a good QuickStart example.

If you think about the responsiblity of the Transfer object, it is to manage the Transfer of an Employee to another Office. I would design this with the Transfer object being separate from both the Employee and the Office, but having a reference to each. The Transfer object would probably have an Enum of approval status values and on reaching an end-state (cancelled or final approval) the Transfer object could perform the action of associating the Employee with the new Office and mark itself as completed. It is not bad design for the Transfer object to have references to the other objects. The relationship between Transfer and Employee (and also Transfer and Office) in this case a "uses" relationship.