Tag: Entity

I’m struggling to think of a concise way to phrase the question, but assume you were developing an application that managed employees at various company branches. You could potentially model this part of the application like this:

It’s stipulated that every employee must belong to exactly one branch. To enforce this, you’d pass the branch the employee operates at to the Employee constructor and make the corresponding property immutable:

class Employee {

    public Employee(int id, string name, Branch operatesAt)
    {
        Id = id;
        Name = name;
        OperatesAt = operatesAt;
    }

    public int Id { get; }
    public string Name { get; }
    public Branch OperatesAt { get; }
}

You might then choose to model the Branch class like this:

class Branch {

    private readonly List<Employee> _employees;

    public Branch(int id, string name, ICollection<Employee> employees)
    {
        Id = id;
        Name = name;
        _employees = employees.ToList();
    }

    public int Id { get; }
    public string Name { get; }
    public IReadOnlyCollection<Employee> Employees => _employees.AsReadOnly();
}

In my application I’m using EF Core, and something similar to these models would work fine. I’m following Microsoft’s architectural recommendations for ASP.NET Core development, and as such I’m trying to use a domain-driven approach to modelling the entities that EF Core operates with. This is why I’m trying to use constructors to ensure my entities can only ever exist in a valid state and prevent mutation of these entities except through methods that represent domain-relevant operations.

However, trying to manually setup a new branch with employees (for example, in tests) exposes a chicken and the egg problem:

var branch = new Branch(id: 1, name: "Example branch", employees: new()
{
    new ProductConsultant(id: 12345, name: "John Smith", operatesAt: um...)
});

Is this a common issue to run into, and if so is there a well-defined solution to it? Someone I discussed this with mentioned the builder pattern could work. An alternative that I’m thinking of going with is to define a factory method on the principal entity that constructs, registers and returns an instance of the dependent entity:

class Branch {

    private readonly List<Employee> _employees;

    public Branch(int id, string name)
    {
        Id = id;
        Name = name;
        _employees = new List<Employee>();    
    }

    public int Id { get; }
    public string Name { get; }
    public IReadOnlyCollection<Employee> Employees => _employees.AsReadOnly();

    public Employee RegisterNewEmployee(int id, string name)
    {
        var employee = new Employee(id, name, this);
        _employees.Add(employee);
        return employee;
    }
}

Is this a suitable approach, or is there something more appropriate that can be done here?