Why interfaces for message contracts are strongly recommended in MassTransit?

Question

MassTransit states that we should use interfaces for message contracts :

It is strongly suggested to use interfaces for message contracts, based on experience over several years with varying levels of developer experience. MassTransit will create dynamic interface implementations for the messages, ensuring a clean separation of the message contract from the consumer.

Source : Docs » Using MassTransit » Creating a message contract

What is downside of using POCO DTOs instead of interfaces, what are the obvious advantages of Interfaces over classes in the context of messaging with MassTransit?

On the other hand NServiceBus is fine with POCO, and sure it makes sense to not use internal classes like domain object, see below.

Source : NServiceBus » Messaging » Messages, Events and Commands

When creating messages one should follow the following guidelines:

Messages should be simple POCO objects.

Messages should be as small as possible.

Messages should satisfy a Single Responsibility Principle.

Classes used for other purposes (e.g. domain objects, data access objects and UI binding objects) should not be used as messages.

Pretty simple what the advantages are: ensuring a clean separation of the message contract from the consumer — Jamie Rees
Wouldn't POCO be like 2nd best? I mean the wording - "strongly suggested" implies some sort of risk or negative consequences of not using interfaces, which I fail to see at this moment. — Edgars Pivovarenoks
The Interface would just be a layer of separation to allow changes to the POCO methods to only have to be migrated ton one block of code. There could be dozens of different save commands throughout the code that would need to be edited on a simple table change, but if those commands just funnel to a Save interface you would only need to edit the 1 instance — Mad Myche
It's guidance, to ensure that behavior doesn't creep into message contracts. POCO usage is certainly allowed, most teams porting from NSB don't change their message assemblies and they work just fine. — Chris Patterson
@ChrisPatterson that is no longer the case with the next C# where interfaces can contain functionality :-) — Carlo V. Dango

Siim Haas Siim Haas · Accepted Answer · 2017-06-05T12:47:10

Although not directly related to MassTransit, but I would say the reason is encapsulation. Creating a simple POCO with setters, but passing it on behind interface that promises only getters encapsulates the data in the DTO.

public class Program
{
    static void Main(string[] args)
    {
        User user = new User()
        {
            Username = "user99"
        };

        Account account = new Account(user);
    }
}

public interface IUser
{
    string Username { get; }
}

public class User : IUser
{
    public string Username { get; set; }
}

public class Account
{
    private IUser user;

    //Currently used in main
    public Account(User user)
    {
        user.Username = ""; //This is allowed            
        this.user = user;
    }

    //But consider this ctor
    public Account(IUser user)
    {
        //user.Username = ""; //Not allowed
        this.user = user;
    }

    ...
}

Why interfaces for message contracts are strongly recommended in MassTransit?

2 Answers