售后商城重构—AzureFunctions问题列举

在列举其他问题之前先说一个十分严重的问题的，这个问题在发现的时候就立马修改了。

这个AFSStore.AzureFunctions项目中充满了这样的sql语句。

我们是Code First，而且我们开发初期，数据随时都可能改动，意味着这些代码全要跟着改动，而且是要一个一个字段比对，耗时耗力还容易出差。所以发现的时候里面拨乱还反正。

下面我们继续列举AFSStore.AzureFunctions还存在哪些问题，先看看现在的结构：

1，首先售后商城后端包含两部分AFSStore.AzureFunctions和AFSStore.WebApi，一个是做定时任务，一个是提供Api接口。把这两个项目放在同一个解决方案中就是为了共用一些基础服务，从而降低开发成本。看上图中的结构不难发现这就是一个项目该有的模板都包含。相当于在一个解决方案中做了两套系统，背离了我们的初中。

2，看下图Function的入口，里面还是用new的方式构建类，显然不是一个好的方式。在Azure Functions 2.x中微软官方已经开始支持依赖注入了。

3，AFSStoreProductSyncRunner看下面截图可以看出来，这个文件主要是存放业务服务接口和实现，所以应该放在3-Service中。

4，看下图不难发现Contracts和Models都是DTO相关的模型契约，应该放到2-Contract中，当然还要根据模型的具体用途再确定是应该放在AFSStore.Contracts中还是放在AFSStore.Provider.Contracts中，后面再详细说明。

5，如下图Proxy是调用Product Center做数据同步的，因此应该放到3-Service/AFSStore.ExternalService.Facade中。

6，很显然Services应该放在3-Service中。

7，下图中这些代码应该根据其功能是否放在0-Common中。

后面我们将一一解决这些问题。