Asp.Net Core Deserialize Interface Type

Question

I am working on an Asp.Net Core application where I have defined a service that is responsible for storing the request into a SQL database. My Request consists of three properties Id, RequestType, and a SpecificRequestDto. The RequestType is an enum that specifies whether is it a Flight booking request, hotel booking request, or a RailBooking request. For instance, the SpecificRequestDto can be a FlightBookingRequest, HotelBookingRequest, RailBookingRequest. My request class

public class Request
{
  public int RequestId{ get; set; }
  public RequestType RequestType{ get; set; }
  public IRequestDto RequestDto{ get; set; }
}
public class FlightBookingRequestDto : IRequestDto
{
 
}
public class HotelBookingRequestDto : IRequestDto
{

}
public class RailBookingRequestDto: IRequestDto
{

}

My request JSON can either FlightBookingRequestDto, HotelBookingRequestDto, or RailBookingRequestDto in the RequestDto property. Now my application cannot determine the type of RequestDto as I am sending an interface type and hence cannot be de-serialized. I have made the RequestDto as string property and sending the FlightBookingRequestDto, HotelBookingRequestDto, or RailBookingRequestDto as Json string and de-serializing it in my application based on RequestType.

I would like to know whether is it the right approach or Asp.Net core has a better solution for it. I am currently using the AspNet Boilerplate template.

Answer 1

There is a time and a place for using Interfaces and DTO objects are not a good use case.

Your DTOs should serve one purpose: get data across a technology agnostic boundary from Point A to Point B (and back again). Once the DTO has served that purpose the data should be mapped as required into more technology-relevant structures that may include behaviour (methods).

If you are using an Interface, this would indicate that your DTOs have behaviour (methods) as well as data. That's not a good idea.

Ultimately, the main use case of an implementable Interface is to provide a common set of methods that can be implemented differently by various implementors of that Interface. If your DTOs are just data without functionality (which they should be - they are Data Transfer Objects) then a single class that has the properties (instead of using an interface) should do the job.

Following Question Edit

It looks like all of your requests are very similar (would be good to see your IRequestDto interface to confirm), but based on what I can see I would recommend:

Create a BookingRequest class:

public class BookingRequest
{
    public int RequestId { get; set; }
    public RequestType RequestType { get; set; }
    // and some assumptions about your IRequestDto interface ...
    public DateTime BookingTime { get; set; }
    public string RequestorName { get; set; }
    public string RequestorEmail { get; set; }
    // ... etc.
}

Then your service

public async Task<ActionResult<BookingConfirmation>> RequestBooking(
    BookingRequest request)
{
    // Do common stuff
    // Check request.RequestType to do specific stuff
}

Alternatively, if your different requests vary considerable, then create a dedicated service method for each, each with its own request class.

But, definitely get rid of that IRequestDto. That's gonna cause you pain. If you really want to share elements of the request then create a base class request and inherit from that, but have your Service Requests focused against each specific request class derived from that base class.