售后商城重构—AFSStore.WebApi重构

先给大家看看AFSStore.WebAp现在的结构：

我一一为大家介绍并进行重构。

1，Attributes是存放各种特性和过滤器的，比如异常处理，身份认证，Usid参数必传等。

这部分功能明确，代码简介没啥优化的地方。

2，Controllers中就是各个业务的控制器。

首先OrderCenterCallbackControllers中放的是OrderCenter回调接口，这块是根据我们公司内部的统一模式创建订单的，所以这里的代码都是约定好的统一模式。

而v1和v2是应为我们的api是支持版本号的，现在我们项目是刚开发所以都是放在v1中。

下面我们就来一个一个文件看。

1，ActivedCampaignController：

继续查看返回类型GetCampaignDetailResponse：

继续查看CampaignDto：

看到这儿我们就发现了问题了，对于一个返回的DTO很显然这些特性有些多余。我们把多余的特性删除：

同时我们还发现CampaignDto中有个Products属性：

继续深入ProductDto：

我们发现这个一个全量数据，

这个接口是为了实现活动页面显示一个活动图片以及一些活动介绍，并且显示参加活动的产品列表，效果图如下：

很显然产品数据是不可能需要所有的产品字段的，只需要价格，标题，描述，图片等少量字段。像创建日期更新日期，备注等这些字段传给前端有啥意义呢？

查看这个类的所有引用：

不难发现这个这个类被好多地方引用，这样的结果就是这个类是所有调用接口的需求的集合，而且这个类的修改只能进行增量添加，而不能做减量，因为你不知道你的修改会影响到多少地方，这个类会不停的膨胀，显然这样是不正确的。其实处理这样的问题很简单，我们应该根据不同的需求创建不同的DTO，完全没有必要为了省点事，就共用同一个DTO，虽然这样可能导致DTO数量增加，但是代码清晰合理的，也是可维护的。

所以我们新建CampaignProductDto：

只保留一些必要字段即可。

其实我们在做api的时候，入参，出参，最后就保持我们业务必须的需求，最多冗余少量影响不大，后面需要的可能性很大的字段，不然不要写过多额外的字段，既增加前端的工作的难度，也影响接口性能。

其余的控制器还要很多类似的问题，我就不在这里一一列举了。

至于这一块也都是基础设施代码，优化空间不大，就不在这里说了。

AFSStore.WebApi中主要的问题技术关于DTO使用的问题，重构就到这了。后面我们继续往下3-Service层重构。