Name Converters After The Output Type

Photo by Designnn.co on Unsplash

The question came up again. What shall we call a type converting from a source type to a destination type? Say, from an Order to a DbOrder? How about OrderToDbOrderConverter?

Wouldn’t that mean that other source inputs producing the same destination object, DbOrder, required another converter class? Say SalesInvoiceAndPurchaseStatusToDbOrderConverter? That’s a rather long name.

With conversions, we are primarily interested in the resultant type—here DbOrder. That’s the type we need to carry on with our program. 

So, I suggest that we name converters after the output type. If we are converting to DbOrder then the converter type would shorten to DbOrderConverter. For ease of use, all the methods become overloads of Convert() or Map(). The source conversion types become the input parameters.

For example:

  public class DbOrderConverter
  {
     public DbOrder Convert(Order order)
     {
        // Convert from Order to DbOrder 
     }

     public DbOrder Convert(SalesInvoice salesInvoice, PurchaseStatus purchaseStatus)
     {
        // Convert from SalesInvoice & PurchaseStatus to DbOrder 
     }
  }

The only caveat with this approach is that we carefully construct converters to be aware of only one mechanism at a time. For example, if a converter knows how to convert both an ApiOrder, a web type, and a DbOrder, a database persistence type, to an Order, a business logic type, then this is a problem. 

Why?

Consider this: Where would such a converter type be located? Within the database project? Now the database project would have to know about web! What about the web project? Not any better—the web project would need to reference and become coupled to the database project. 

What is required here would be two separate converters, each serving one adjacent transition between architectural layers.