I have seen many changes in the world of programming languages. One of the most recent additions to the C# language is the Record type. At first glance, it may seem like Records are just another way to define classes, but they offer unique features that can make them a better choice than traditional classes in certain situations.

In this article, I will explain why we should use Records in C# and when they are the better choice over classes.

What are Records?

Records are a new type introduced in C# 9.0. They are similar to classes in that they allow us to define types with properties and methods. However, Records have some key differences that make them unique. One of the most significant differences is that Records are immutable by default, which means that once we create an instance of a Record, we cannot modify its properties. This immutability makes Records a great fit for representing data that should not change once it is created, such as data transfer objects (DTOs), configuration data, and values from a database or web service.

Another key difference between Records and classes is that Records provide value-based equality by default. When we compare two Records, their values are compared rather than their references. This feature is very useful when we want to compare two instances of a type to see if they have the same data, regardless of whether they are the same object in memory.

When to use Records?

Now that we know what Records are and how they differ from classes let's talk about when to use them. As mentioned earlier, Records are ideal for representing immutable data that should not change once it is created. Here are a few examples of when to use Records:

  • DTOs - Data Transfer Objects are used to transfer data between layers of an application or between applications. Since DTOs are not supposed to change, Records are an excellent fit for representing them.
  • Configuration data - Configuration data contains settings that are used to configure an application or service. Since these settings should not change during the runtime of the application, using Records to represent configuration data makes sense.
  • Values from a database or web service - When we get data from a database or web service, we often want to represent that data in our application. Since this data should not change once it is retrieved, using Records to represent it is a good choice.
  • Small objects - If we have a small object with a few properties, using a Record instead of a class can simplify our code and make it more concise. When to use classes instead of Records?

While Records have many benefits, there are situations where they are not the best choice. Here are a few examples of when to use classes instead of Records:

  • Mutable objects - If we need to create an object that can change over time, we should use a class instead of a Record.
  • Inheritance - If we need to create a type hierarchy with inheritance, we should use classes instead of Records.
  • Large objects - If we have an object with many properties, using a Record can make our code more complex, and we should use a class instead.

Conclusion

Records are a valuable addition to the C# language that can simplify our code and make it more concise. They are a great fit for representing immutable data that should not change once it is created, such as DTOs, configuration data, and values from a database or web service. While Records are not always the best choice, they offer unique features that make them an excellent tool to have in our toolbox. As with any tool, we should evaluate the situation and choose the right tool for the job.