Net Core:为每个 API 操作创建响应 Class?
Net Core: Create Response Class for Each API Action?
我们的软件架构师要求所有 API 操作都有自己的响应 Class,因为每个响应都可能略有不同。所以我们基本上将 Product DTO 包装在一个 Base Response class 中,并在需要时稍微自定义。这是好的架构实践吗?我开始编程,它似乎有点重复。另外,什么是更好的最佳替代方案?
产品Class:
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;}
}
至少对于当前的例子,我会说它有点想多了。
有很多派生类没有自己的附加属性。可能在未来,相同的模式将继续存在。
更好的解决方案是将 BaseResponse 作为一个接口,以便更好地扩展以实现多个不同接口的相同属性。
下面是更详细的信息。
看到这段代码很难说good/bad架构实践。在我们的例子中,我们使用下面的模式并发现它是合理的
public class BaseResponse
{
public bool HasError { get; set; }
public string Error { get; set; }
}
public class CreateProductResponse : BaseResponse
{
---
}
public class CreateProductDetailResponse : CreateProductResponse
{
---
}
我们的软件架构师要求所有 API 操作都有自己的响应 Class,因为每个响应都可能略有不同。所以我们基本上将 Product DTO 包装在一个 Base Response class 中,并在需要时稍微自定义。这是好的架构实践吗?我开始编程,它似乎有点重复。另外,什么是更好的最佳替代方案?
产品Class:
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;}
}
至少对于当前的例子,我会说它有点想多了。 有很多派生类没有自己的附加属性。可能在未来,相同的模式将继续存在。
更好的解决方案是将 BaseResponse 作为一个接口,以便更好地扩展以实现多个不同接口的相同属性。 下面是更详细的信息。
看到这段代码很难说good/bad架构实践。在我们的例子中,我们使用下面的模式并发现它是合理的
public class BaseResponse
{
public bool HasError { get; set; }
public string Error { get; set; }
}
public class CreateProductResponse : BaseResponse
{
---
}
public class CreateProductDetailResponse : CreateProductResponse
{
---
}