What is association between classes in object-oriented design? Explain multiplicity, direction (unidirectional versus bidirectional), how associations appear in C# code and EF Core, and the problems bidirectional associations cause.

1. Association vs other relationships

Aggregation and composition are special kinds of association; the distinctions matter mainly for lifetime and deletion rules.

2. UML notation

Customer 1 -------- * Order          (association with multiplicity)
Order    * -------> 1 Customer       (navigable one way: unidirectional)
Order    ◆-------- * OrderLine       (composition)
Team     ◇-------- * Player          (aggregation)

Role names (e.g. placedBy) can label association ends, and the same two classes can have multiple associations (Order.BillingAddress, Order.ShippingAddress).

3. EF Core relationship mechanics

• Foreign key properties are the source of truth in the database; navigations are object-level views.
• The change tracker performs relationship fix-up: when you set a foreign key or add to a collection of tracked entities, EF Core updates the inverse navigation automatically. Outside tracking (new objects in tests, no-tracking queries with identity resolution off), you must manage both sides.
• Required vs optional relationships map to nullable FKs and affect delete behaviour (Cascade, Restrict, SetNull, ClientSetNull).
• Shadow FKs: EF can create FK columns without CLR properties, but explicit FK properties make updates without loading the principal easy (order.CustomerId = id).

4. Navigation properties and queries

• Include loads related data eagerly; multiple collection includes can cause cartesian explosion — use AsSplitQuery().
• Projections (Select(c => new { c.Name, OrderCount = c.Orders.Count() })) translate to efficient SQL and avoid loading entities at all.
• Lazy loading proxies make every navigation access a potential query (N+1), often hidden in serialisation or loops.

5. Designing association direction

Ask: which use case navigates from A to B? If only one direction is needed, model only that. A collection navigation on the "one" side is often unnecessary when the use case can query by FK. Many teams keep a reference navigation on the dependent (Order.Customer) for queries and omit large collections like Customer.Orders, which can be unbounded.

6. Associations across module boundaries

In a modular monolith or microservices, associations across boundaries should be IDs only. The Ordering module stores CustomerId; it doesn't have a Customer entity from the CRM module. Data needed from the other module is fetched through its API or replicated via events (e.g. a local read model of customer names).

Try it yourself

1. Create Customer and Order plain classes with bidirectional navigations and write a test showing inconsistency when only one side is set.
2. Map the same model in EF Core and observe fix-up with tracked entities.
3. Serialise a customer with orders using System.Text.Json and see the cycle exception.
4. Rewrite an endpoint to use a projection instead of Include and compare the SQL.

// Unidirectional association by identifier (across aggregates)
public readonly record struct CustomerId(Guid Value);

public sealed class Order(CustomerId customerId)
{
    public CustomerId CustomerId { get; } = customerId;    // knows the customer, does not own it
}

// Bidirectional association kept in sync by one side
public sealed class Course(string code)
{
    private readonly List<Enrolment> _enrolments = [];
    public string Code { get; } = code;
    public IReadOnlyList<Enrolment> Enrolments => _enrolments;

    public Enrolment Enrol(Student student)
    {
        var e = new Enrolment(student, this);
        _enrolments.Add(e);
        student.AddEnrolment(e);           // keep the other end consistent
        return e;
    }
}

public sealed class Student(string name)
{
    private readonly List<Enrolment> _enrolments = [];
    public string Name { get; } = name;
    public IReadOnlyList<Enrolment> Enrolments => _enrolments;
    internal void AddEnrolment(Enrolment e) => _enrolments.Add(e);
}

// Many-to-many modelled as its own concept
public sealed class Enrolment(Student student, Course course)
{
    public Student Student { get; } = student;
    public Course Course { get; } = course;
    public string? Grade { get; set; }
}

// API boundary: DTOs break cycles
public sealed record StudentDto(string Name, IReadOnlyList<string> CourseCodes);
static StudentDto ToDto(Student s) =>
    new(s.Name, s.Enrolments.Select(e => e.Course.Code).ToList());