2

我们的软件架构师要求所有 API 操作都有自己的响应类，因为每个响应都可能略有不同。因此，我们基本上将 Product DTO 包装在 Base Response 类中，并在需要时稍微定制。这是良好的架构实践吗？我开始编程，它似乎有点重复。此外，什么是更好的最佳选择呢？

产品类别：

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

基本响应：

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

个人回应：

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;}
}
4

2 回答 2

0

至少对于当前的示例，我会说这有点多虑了。有许多派生类没有其他自己的属性。可能在未来，同样的模式将继续存在。

更好的解决方案是将 BaseResponse 作为一个接口，以获得更好的可扩展性，以实现几个不同接口的相同属性。下面是更详细的信息。

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

于 2019-09-22T15:31:46.020 回答
0

看到这段代码很难说好的/坏的架构实践。在我们的例子中，我们使用下面的模式并发现它是合理的

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


public class CreateProductResponse : BaseResponse
{
 ---
}

public class CreateProductDetailResponse : CreateProductResponse
{
 ---
}
于 2019-09-22T17:47:20.780 回答