接口开发原则

在整个项目开发中，业务层开发是一个逻辑整合的过程，既参考前台展示又参考DB层的提取。

它是前台数据和DB数据相互转换的机器，既向前台提供系列接口，又调用DB提供的接口。

在接口定义中，又该如何把控。

个人建议：

1、接口有明确的目的

2、传入参数和传出参数要考虑接口的目的，不能整合代替

3、理解一目了然

举例：

A、需要一个最近100条前台展示的列表

接口传入：待输出条数

接口传出：一个集合

根据需要，可以指定特定的集合类型，比如DataTable，Reader等

在此，个人定义此接口：

/// <summary>
/// 获取最近列表
/// </summary>
/// <param name = "count">指定列表条数，0=所有</param>
/// <returns>返回数据集</returns>
IDataReader GetThelastestList(int count);

B、指定范围内（此范围跟业务逻辑有关，不做特定描述），需要某用户的订单的产品数量，需要某用户已支付成功的产品数量

分析语句，在业务逻辑上，两个数据都需要使用（也许同时使用，也许不同时）

这里需要注意的，以下情况估计你也遇到过：

业务开发者，理解上述需求，告知DB层开发者：提供一个接口，需要XXX,YYY,ZZZ参数，返回数据集

如果开发团队是总体设计者+Coder，那么DB开发者，直接写就行了，描述清楚。

如果开发团队是总体设计+分层设计以及实现，那么所有分层设计之间的接口，必有一个设计文档，通过此文档分别分析，磨合调用相关的接口。若需要对方提供接口，应告知对方接口目的，由对方来设定接口的输入和输出。这样的话：上面的描述就会导致DB开发者不明了，输入和输出以及接口本身的意义，交流本身就是混乱的

分解下业务开发者的话：按照原描述意义，可以得知业务开发者需要的一个集合，这个集合有用的订单数量、成功支付的数量

整理下来数据集结构就是：

数量A    支付状态

数量B    支付状态

等

这样按照此思维，接口如下：

/// <summary>
/// 
/// </summary>
/// <param name="userID"></param>
/// <returns></returns>
public IDataReader GetXXXXXXXCount(int userID)

按照原始需求，告知DB层开发人员，定义接口如下：

/// <summary>
/// 获取用户下单的产品数量
/// </summary>
/// <param name="userID"></param>
/// <returns></returns>
public int GetUserOrderCount(int userID);

/// <summary>
/// 获取用户成功支付订单的产品数量
/// </summary>
/// <param name="userID"></param>
/// <returns></returns>
public int GetUserBuyCount(int userID);

比较二者接口：

前者接口无法准确描述接口的性质和目的

后者一目了然的知道此接口用于何处

有时候，从DB层来说，数据的来源同一个，但接口输出却不能揉杂在一起

Ps：

接口性质，个人定义

列表类接口：返回一个集合

信息类接口：返回一个单（少量）记录集合或字段或空

操作类接口：返回一个状态或字段或空或影响数等