Immutable DTOs in C# 12 with Record Types

Data on the wire should not be a moving target. When a value crosses a network boundary, lands in a message queue, or feeds a UI layer, it needs to behave predictably. Mutations midway through that journey are a common source of bugs in distributed systems, particularly along the Sydney-to-Frankfurt latency belt used by many Australian banks.

DTOs — Data Transfer Objects — exist precisely to keep that data stable. They are the carriers between your domain, your service layer, and your external callers. As the .NET ecosystem has matured, the language features for building these carriers have shifted from hand-rolled classes toward something far more ergonomic: record types.

The arrival of C# 12 brought further refinements to the record story. Primary constructors on regular classes, collection expressions, and improved required member enforcement all pair well with records when you want your DTO surface to be both concise and impossible to mutate by accident.

This piece walks through why records became the preferred vehicle for immutable DTOs, how C# 12 sharpens them, and where they are a poor fit. It also touches on practical patterns seen in production codebases from Brisbane to Perth.

The Evolution of DTOs in C#

Before records landed in C# 9, most teams wrote DTOs as plain classes with read-only properties, verbose constructors, and an Equals override they often forgot to update. A single Address DTO could easily run to forty lines, and engineering teams at places like REA Group or Atlassian frequently cited that verbosity as a tax on every API contract review.

Records collapsed that boilerplate into a single line for the simple case. A positional record declares its shape, its constructor, its Deconstruct method, and value-based equality in one expression. That collapse is not just cosmetic — it reduces the surface area where a junior developer can introduce a bug.

The trend continued with C# 10's record struct, and C# 12's primary constructors on classes blurred the line further. Today you can choose between reference records, value records, or a regular class with primary constructor parameters, depending on whether you want identity, value semantics, or a familiar object graph.

Records vs Classes vs Structs

Picking the right type is a design decision, not a stylistic preference. A record class gives you value-based equality and immutability hints, but it still lives on the heap, ships with the same garbage collection profile, and pays the indirection cost of a reference. That profile fits well for DTOs that travel over HTTP or JSON, where the object may be passed around many services.

A record struct is a value type. It can avoid heap allocation entirely when used carefully, but copying grows with the size of the record. For small payloads — a token, a coordinate, a status flag — record structs shine. For a fat Product or Order DTO with embedded lists, the copy cost outweighs the benefit.

Regular classes with the new primary constructor syntax occupy a middle ground. You can mark fields as readonly, keep familiar syntax, and avoid the value-semantics surprises that occasionally catch developers off guard when a record struct is passed into a generic constraint. Each option has a place, and the wrong choice usually shows up as either allocation churn or a flaky test that hinges on reference equality.

Positional Records and required Members

Positional records are the canonical syntax for DTOs in modern C#. You list the members in the parameter list, and the compiler synthesises the property, the field, the constructor, and the deconstructor:

public record OrderDto(string OrderId, string CustomerName, decimal Total);

That single line carries a lot of weight. The OrderId and CustomerName are init-only properties, so they can be set during construction but not after. The Total cannot drift below zero unless you add validation, and equality comparisons between two OrderDto instances compare member by member.

C# 12's refined required keyword now applies to any property — not just records. You can pair it with records to ensure the caller cannot accidentally omit a field:

public record AddressDto(required string Line1, string? Line2, required string Postcode);

The compiler will refuse to build until the caller supplies a Line1 and Postcode. This combination of immutability and requiredness is particularly useful for DTOs that fan out across microservices, where a missing field would otherwise be detected only at runtime in some far-away region.

Pattern Matching and Serialisation

Records pair beautifully with switch expressions. The positional syntax lets you deconstruct a DTO directly in a case label, which reads almost like a spec:

return order switch
{
    { Total: > 1000 } => "high-value",
    { CustomerName.Length: 0 } => "anonymous",
    _ => "standard"
};

Pattern matching against DTOs is a common pattern in notification hubs and event routers, where the shape of the message decides downstream behaviour. Records make that pattern terse and reliable, and they encourage code reviewers to read DTO branches as data rather than as control flow.

For serialisation, both System.Text.Json and Json.NET handle records without ceremony. Init-only properties are populated during deserialisation, and the default JSON converter respects value-based equality. A common pattern in Australian fintechs is to round-trip an OrderDto through a Service Bus queue and verify equality after deserialisation — a check that records make trivial.

Real-World Trade-Offs and Migration

Records are not a free upgrade. Their ToString() override dumps every member into the returned string, which can leak sensitive data into logs. Teams at organisations like Commonwealth Bank, Westpac, and several Melbourne-based health platforms often disable that override on DTOs that carry PII, replacing it with a redacting implementation or an explicit [DebuggerDisplay].

There is also the matter of inheritance. Records support record Derived : Base, but positional inheritance is restricted, and deep hierarchies can confuse serialisers. If your DTO graph is shallow — and most are — records are ideal. If it runs through four layers of abstraction, a regular class may be easier to reason about.

Finally, if you are still moving older code off the .NET Framework, you will eventually need a strategy for those legacy DTOs too. A useful walkthrough is the recent piece on migrating legacy .NET Framework apps to .NET Core on Azure, which covers how immutable payload contracts travel cleanly across the boundary once the runtime upgrade is in place.

When introducing records in a long-lived codebase, a staged rollout reduces friction. Start with new DTOs rather than migrations, train reviewers on the value-semantics model, and add an analyser rule to catch accidental setters on what should be immutable types.

A quick comparison across the three options follows, summarising the trade-offs in greenfield code under C# 12:

Rolling out records without friction

A short adoption checklist for teams in Australia's .NET community looks like this:

• Replace class with record on public DTO shapes first
• Use required on fields that the deserialiser must populate
• Override ToString for any DTO that may appear in logs
• Avoid record structs larger than a handful of properties unless profiling demands them

Patterns that consistently show up in code reviews here:

• Positional records for inbound and outbound DTOs
• with expressions for creating modified copies without mutating the original
• Switch expressions for routing decisions based on DTO shape
• Explicit Equals overrides only when collections or computed fields need custom handling

Run that experiment on your own codebase before the next sprint planning session, and bring the line-count delta to the discussion. Your team will either cheer the cleanup or surface reasons to stay where you are, and either result is useful.