Net Core: Create Response Class for Each API Action?

Question

Our software architect is mandating all API Actions have their own Response Class, since every Response can be slightly difference. So we basically wrap the Product DTO in a Base Response class, and slightly customize if needed. Is this good architectural practice? I started programming and it Seems kind of repetitive. Also, what is a nicer optimal alternative for this?

Product Class:

public class ProductDto
{
    public int ProductId { get; set;},
    public string ProductName { get; set;},
    public string ProductDescription { get; set;},
    public float SalesAmount { get; set;}
}

BaseResponse:

public class BaseResponse<T>
{
    [Required, ValidateObject]
    public T Body { get; set; }
    public bool HasError { get; set; }
    public string Error { get; set; }
}

Individual Response:

public class CreateProductResponse : BaseResponse<ProductDto>
{
}

public class DeleteProductResponse : BaseResponse<int>
{
}

public class GetAllProductResponse : BaseResponse<IEnumerable<ProductDto>>
{
    public int Count { get; set;};
}

public class GetProductResponse : BaseResponse<ProductDto>
{
}

public class UpdateProductResponse : BaseResponse<ProductDto>
{
    public date DateUpdate { get; set;}
}

Main developer's task is to make a complex problem simple and more understandable, if repetition in code helps it, I believe that it's not bad. In the case you have mentioned, I think, that is not a repetition, it is kind of `inheritance` with `Generic type` which is acceptable. — Abbas Amiri, Sep 22 '19 at 13:33
Check out: https://stackoverflow.com/questions/23648832/viewmodels-in-mvc-mvvm-separation-of-layers-best-practices — Stefan, Sep 22 '19 at 15:34
You (and the architect) might be interested in GraphQL instead of building your own protocol. — huysentruitw, Sep 22 '19 at 18:59
Hi @huysentruitw I read about graphql, in which sense would this help? still need to create different models for response types, what is recommended solution, feel free to place in answer, thanks- — , Sep 22 '19 at 19:16
Yes, you'll need different models, but you'll no longer have to wrap them inside a generic. — huysentruitw, Sep 23 '19 at 11:06

Andrius · Accepted Answer · 2019-09-23T06:49:45.500

At least with a current example, I would say it's a bit overthinking. There are many derived classes who have no additional its own properties. Probably in the future, the same pattern will stay on.

A better solution would be to make BaseResponse as an interface for better extensibility for implementing same properties of several different interfaces. Below it's more detailed information.

https://softwareengineering.stackexchange.com/questions/382882/why-inherit-a-class-and-not-add-properties

score 0 · Answer 2 · answered Sep 22 '19 at 17:47

it's difficult to say good/bad architectural practice by seeing this piece of code. in our case, we use the below the pattern and find it reasonable

public class BaseResponse
{
    public bool HasError { get; set; }
    public string Error { get; set; }
}   


public class CreateProductResponse : BaseResponse
{
 ---
}

public class CreateProductDetailResponse : CreateProductResponse
{
 ---
}

Net Core: Create Response Class for Each API Action?

2 Answers2