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.