Question

I am creating a class library for a project management application. I will brief you on how all the entities are setup to aid in question.

A user subscribes to a plan during registration. Every plan contains modules/applications he can use after successful verification of his account. Project, Company and Plans are the modules for which i am creating the class library and these are the modules that exist at every stage of the user life cycle. Roles determine what the user can perform or not. Each company(only one for a user) can house many projects and each project have dedicated Project Lead with his resources. Project Lead is another user with higher privileges/Roles. Now here is the confusing part because both seems fine to me:Which of the class hierarchy i should follow 1 or 2

1

User

  - Subscriptions ( List<> )

  - Projects ( List<> )
      - Client ( Client )
      - ProjectLead( User )
      - Resources(List<>)

2

Application

   - Projects ( List<> )

     - Client ( Client )
     - ProjectLead ( User )
     - Resources ( List<> )

User

  - GetProjects ( List <Project> )

Confusion barely comes to this point, the client is associated with project through foreign key ProjectId. So while creating a class for Client ,

to denote which project the client belongs should i create a Project
Class inside Client class or Should client be housed inside the
Project Class.

Answer 1

Do I understand correctly that you are confused which object should have a relation with another object, like this:

option 1: a user HAS projects (where he is the LEAD)
option 2: a project HAS a user (which is the lead)

And more of that.

The good news is: you don’t have to choose. You can write a bidirectional relationship.
There are several ways to implement this.

Because you talk about foreign keys, am I right in assuming you are using a backend database to persist the objects? In that case, you can use an Object-Relational database Mapper (ORM) like Entity Framework. If not, you’ll have to do some work yourself, which is something I’d personally avoid 😉

Entity framework

You just write your database with all relationships first and then let entity framework generate the corresponding classes for you. All these classes have bidirectional relationships.

Example:

You have two tables:

• Users
  • id: int
  • Name: nvarchar(50)
• Projects
  • id: int
  • LeadUserId: int FOREIGN KEY to Users.id
  • Name: nvarchar(50)

Entity framework will translate this into two classes like this

• User

  • id: int
  • Name: string
  • Projects: List

• Project

  • id: int
  • Name: string
  • User: User

When you now for example set the ‘User’ field of a Project object to a different user, the project is automatically removed from the Projects list of the original user, and is added to the new user’s Projects list.

You can persist changes to the database by calling a .SaveChanges() method on the database context object.

Write your own bi-directional association

The main problem with bi-directional relations is that you have to maintain consistency. With simple one-to-one relationships it’s not that bad, but with one-to-many relationships (as is the case here, one user to many projects) it’s a bit more difficult.

Below you find an implementation that uses the rather excellent ObservableCollection class.

The Project class

public class Project {
    public string Name { get; set; }

    private User _leadUser;
    public User LeadUser {
        get { return _leadUser; }
        set {
            if (_leadUser != value) {
                if (_leadUser != null) {
                    _leadUser.Projects.Remove(this);
                    if (!value.Projects.Contains(this)) {
                        value.Projects.Add(this);
                    }
                }
                _leadUser = value;
            }
        }
    }
}

The User class

public class User {

    public string Name { get; set; }

    private ObservableCollection<Project> _projects = new ObservableCollection<Project>();
    public ObservableCollection<Project> Projects { get { return _projects; } }

    public User() {
        Projects.CollectionChanged += OnProjectCollectionChanged;
    }

    protected void OnProjectCollectionChanged(object sender, NotifyCollectionChangedEventArgs e) {
        var projects = sender as IEnumerable<Project>;
        switch (e.Action) {
            case NotifyCollectionChangedAction.Add:
                foreach (var project in projects) {
                    if (project.LeadUser != this) {
                        project.LeadUser = this;
                    }
                }
                break;
            case NotifyCollectionChangedAction.Move:
                break;
            case NotifyCollectionChangedAction.Remove:
                foreach (var project in projects) {
                    if (project.LeadUser == this) {
                        project.LeadUser = null;
                    }
                }
                break;
            case NotifyCollectionChangedAction.Replace:
                break;
            case NotifyCollectionChangedAction.Reset:
                break;
            default:
                break;
        }
    }
}

Hopefully this post was useful to you.