Assigning a Resource to a Project in Visual C#.NET

Generating PDF417 in Visual C#.NET Assigning a Resource to a Project

Based on the use cases, resources can be assigned to projects. This implies that the user has identified the project and wishes to assign a resource to it. It also implies that a project has a collection of assigned resources: hence the ProjectResources collection in the object model. But what behavior and information would a user expect from the items in the ProjectResources collection Certainly, one behavior is to return the list of resources assigned to the project. Another behavior is to allow a new resource to be assigned to the project, implying something like an Assign() method that accepts the Id property from a Resource. It is also worth considering what information should be provided to the user. When viewing or editing a Project, the list of assigned resources should probably show something like this: Resource ID Resource name Date assigned to the project Role of the resource on the project This means that ProjectResources, and the items returned by ProjectResources, might look something like Figure 6-3.

Though not visible in Figure 6-3, the Assign() method accepts a resourceId parameter to identify the resource being assigned to the project. Given this analysis, let s consider the behaviors and information required to assign a project to a resource basically the same process, but starting with a Resource instead of a Project.

The use cases provide for the idea that a user could start by identifying a resource rather than a project. In this case, the user can still associate a project with the resource by selecting a project. This implies that the Resource object has a collection of projects to which the resource is assigned. The object model thus far represents this collection as ResourceAssignments. Let s consider the behaviors and information for the ResourceAssignments collection and the items it would contain. In this case, the user starts with a Resource and wishes to assign the resource to a project. So the ResourceAssignments object will have a couple of behaviors: listing the projects to which the resource is assigned, and assigning the resource to a new project. This can probably be handled by an AssignTo() method that accepts the Id property of a Project. The items in ResourceAssignments have the behavior of returning information about the project assigned to the resource. The information of value to a user is likely the following: Project ID Project name Date assigned to the project Role of the resource on the project Figure 6-4 shows the potential ResourceAssignments object and what its items might look like.

The AssignTo() method accepts a projectId parameter to identify the project to which the resource should be assigned.

It is important to notice that the objects described by Figure 6-3 and Figure 6-4 are similar, but they are not the same. Yet they do share at least some common information, if not behavior. Both child classes contain Assigned and Role properties, implying that there s commonality between them. Such commonality is not justification for combining the two classes into one, because their behaviors are distinctly different. The items in ProjectResources have one responsibility: managing information about a resource assigned to a project. The items in ResourceAssignments have a different responsibility: managing information about a project to which a resource is assigned. While this difference may seem subtle, it is a difference nonetheless. It is tempting to consider that the two classes could be merged into one, as shown in Figure 6-5. Of course, ProjectName isn t valid if the user got to this object from a Project object, but it is valid if she got here through a Resource object. The same is true for several other properties.