Design Patterns

Hi,
Hoping someone could provide some direction on how to approach this problem
using any GOF patterns. e.g. A project contains a team and a team contains
zero or more members, each with a specific role(s) e.g. architect,
programmer, DBA etc. Again assuming that each member is either an employee or
a consultant. If there are two questions that need to be answered
# Which employee(s)/consultant(s) are involved in a project?
# In which projects is an employee/consultant involved and in what roles?

I have been beating my head over something similar for the past 2-3 days
without much success. Any help is much appreciated.


Thx!
sd

re: Design Patterns

Do you need to use GOF patterns?

Would storing the data in tables and running queries suffice? (Use
DataSet, Datatables as in memory stores if you don't want to use
external storage)


1) Role Table
2) Person Table (one attribute is Type : emp/con)
3) Project Table
4) ProjectTeam Table



The ProjectTeam contains

ProjectID (FK to Project)
PersonID (FK to Person )
RoleID (FK to Role)


This pretty much tells you all the information (though you need to join
to the other tables to filter by person type or to get more details
like Person Name or Role Name)



Which Emps (or Cons) are on given Project?

SELECT
Person.Name
FROM
Person, ProjectTeam
WHERE
Person.Id = ProjectTeam.PersonID
AND Person.Type = <emp or con>
AND ProjectTeam.ProjectID = <Project's ID>

if you just want a list of all the people on a project, leave out the
Person.Type criterion



On which projects and in which roles is a given person working

SELECT
Project.Name, Person.Name, Role.Name
FROM Role INNER JOIN
(Project INNER JOIN
(Person INNER JOIN ProjectTeam ON Person.ID =
ProjectTeam.PersonID)
ON Project.ID = ProjectTeam.ProjectID)
ON Role.ID = ProjectTeam.RoleID
WHERE Person.ID= <Person's ID>;

re: Design Patterns

Iam not worried about the sql model, these are business objects that will
have to represented in object model since there's a lot more beyond Datasets
here. I was looking for object models here.

Thanks

"alantolan@users.com" wrote:
[color=blue]
> Do you need to use GOF patterns?
>
> Would storing the data in tables and running queries suffice? (Use
> DataSet, Datatables as in memory stores if you don't want to use
> external storage)
>
>
> 1) Role Table
> 2) Person Table (one attribute is Type : emp/con)
> 3) Project Table
> 4) ProjectTeam Table
>
>
>
> The ProjectTeam contains
>
> ProjectID (FK to Project)
> PersonID (FK to Person )
> RoleID (FK to Role)
>
>
> This pretty much tells you all the information (though you need to join
> to the other tables to filter by person type or to get more details
> like Person Name or Role Name)
>
>
>
> Which Emps (or Cons) are on given Project?
>
> SELECT
> Person.Name
> FROM
> Person, ProjectTeam
> WHERE
> Person.Id = ProjectTeam.PersonID
> AND Person.Type = <emp or con>
> AND ProjectTeam.ProjectID = <Project's ID>
>
> if you just want a list of all the people on a project, leave out the
> Person.Type criterion
>
>
>
> On which projects and in which roles is a given person working
>
> SELECT
> Project.Name, Person.Name, Role.Name
> FROM Role INNER JOIN
> (Project INNER JOIN
> (Person INNER JOIN ProjectTeam ON Person.ID =
> ProjectTeam.PersonID)
> ON Project.ID = ProjectTeam.ProjectID)
> ON Role.ID = ProjectTeam.RoleID
> WHERE Person.ID= <Person's ID>;
>
>[/color]

re: Design Patterns

"sd" wrote:[color=blue]
> Hi,
> Hoping someone could provide some direction on how to approach this
> problem
> using any GOF patterns. e.g. A project contains a team and a team
> contains
> zero or more members, each with a specific role(s) e.g. architect,
> programmer, DBA etc. Again assuming that each member is either an
> employee or
> a consultant. If there are two questions that need to be answered
> # Which employee(s)/consultant(s) are involved in a project?
> # In which projects is an employee/consultant involved and in what
> roles?[/color]

My first reaction was the same as the other poster; this looks like a
relational database problem. However, if I were approaching this as an
object model, I would be inclined to use the role pattern. It's closest
cousin in GOF is the strategy pattern. You would have something like a
Person base class that an Employee and Consultant classes would be
derived from. Secondly, you would have a Role base class that could have
Architect, Programmer, etc. as its derived classes.

A person object, whether it be an employee or a consultant, would hold a
reference to one or more role objects (assuming that a person can have
more than one role in a company). This object would determine the role
of the person. You could then have a Project class that would hold a
collection of person objects representing the people involved in the
project. To query a project object you could use the visitor pattern...
And so on.

I'm not saying this is the best or even necessarily a good approach, but
it will hopefully get you started.

re: Design Patterns

sd,
Rather then a GOF pattern you may want to consider an Enterprise Application
Architecture Pattern.

http://www.martinfowler.com/books.html#eaa

It sounds like you want to define a Domain Model for your business objects
http://www.martinfowler.com/eaaCatalog/domainModel.html

Then use Data Mappers to move your data between objects & database.
http://www.martinfowler.com/eaaCatalog/dataMapper.html

Martin has a couple of other patterns that you may find equally useful.

Hope this helps
Jay

"sd" <sd@discussions.microsoft.com> wrote in message
news:1AD396E6-E54D-43BC-83BA-0D44447D29C9@microsoft.com...
| Iam not worried about the sql model, these are business objects that will
| have to represented in object model since there's a lot more beyond
Datasets
| here. I was looking for object models here.
|
| Thanks
|
| "alantolan@users.com" wrote:
|
| > Do you need to use GOF patterns?
| >
| > Would storing the data in tables and running queries suffice? (Use
| > DataSet, Datatables as in memory stores if you don't want to use
| > external storage)
| >
| >
| > 1) Role Table
| > 2) Person Table (one attribute is Type : emp/con)
| > 3) Project Table
| > 4) ProjectTeam Table
| >
| >
| >
| > The ProjectTeam contains
| >
| > ProjectID (FK to Project)
| > PersonID (FK to Person )
| > RoleID (FK to Role)
| >
| >
| > This pretty much tells you all the information (though you need to join
| > to the other tables to filter by person type or to get more details
| > like Person Name or Role Name)
| >
| >
| >
| > Which Emps (or Cons) are on given Project?
| >
| > SELECT
| > Person.Name
| > FROM
| > Person, ProjectTeam
| > WHERE
| > Person.Id = ProjectTeam.PersonID
| > AND Person.Type = <emp or con>
| > AND ProjectTeam.ProjectID = <Project's ID>
| >
| > if you just want a list of all the people on a project, leave out the
| > Person.Type criterion
| >
| >
| >
| > On which projects and in which roles is a given person working
| >
| > SELECT
| > Project.Name, Person.Name, Role.Name
| > FROM Role INNER JOIN
| > (Project INNER JOIN
| > (Person INNER JOIN ProjectTeam ON Person.ID =
| > ProjectTeam.PersonID)
| > ON Project.ID = ProjectTeam.ProjectID)
| > ON Role.ID = ProjectTeam.RoleID
| > WHERE Person.ID= <Person's ID>;
| >
| >

re: Design Patterns

>I am not worried about the sql model, these are business objects that will[color=blue]
>have to represented in object model since there's a lot more beyond Datasets
>here. I was looking for object models here.[/color]


The question as posed is a purely data related question.

At the moment the only goals mentioned are

# Which employee(s)/consultant(s) are involved in a project?
# In which projects is an employee/consultant involved and in what
roles?

No other functionality is detailed.
This makes it hard to guess a design beyond a simple data entity to
object mapping.

For instance

Classes
- ProjectRepository
- Project
- Project Team
- Team Member
- Person

A ProjectRepository contains a list of Projects

Each Project contains a ProjectTeam

Each ProjectTeam contains a list of TeamMembers

Each TeamMember consists of a Person and a Role Identifier (assumes
that Role is just a tag; roles do not require separate functionality;
and that a person can have different roles in different teams)


Finding the Team members for a specific project is trivial.
It is the Project Team for a project

Finding on which teams / roles a given person is working is more
processing, but still conceptually simple
For each project
for each TeamMember
if TeamMember = sought
report Project / Role
end if
end for
end for


Hope this is helpful.
If you have specific further requirements, please post them and we can
re-visit.

Alan.