首页 > 代码库 > 当pageIndex遇上pageNo
当pageIndex遇上pageNo
我们的项目程序里，由于赶项目进度，同时，大家缺乏相应的沟通，在服务层提供的接口里，涉及到分页查询的，有如下三种情形：
l List<OrderInfo> GetOrderList(OrderQueryModel condition, int pageIndex, int pageSize);
l List<OrderInfo> GetOrderList(OrderQueryModel condition, int pageNo, int pageSize);
l List<OrderInfo> GetOrderList(OrderQueryModel condition, PageMode pagedInfo);
对于以上的接口声明，同时涉及到了pageIndex和pageNo，加上缺乏必要的注释，前端开发组人员的调用方式，尤其是获取第一页数据时，就有些犯迷糊了，有的给的是0，有的给的是1。开发经理在review大家的交付成果时，显然就出现bug了。 于是，倡导统一就显得很迫切了，但是由于项目比较庞大，怕修改会带来新的麻烦。
架构师观点：从使用习惯上来看，pageIndex是从0开始的，index嘛；而pageNo表示计数，所以从1开始就比较容易理解了。
技术总监：不管是叫什么名了，就约束前端调用方从1开始传递这个参数。（技术总监的英语水平用一个名牌形容就是TCL）。
我觉得这种重构是值得尽快来做，越往后拖的话可能就越糟糕，就执意坚持。 最后，和开发经理花了2个小时，并做了一些检查，最终修复成如下方案：
分页查询使用统一模型PageModel，其中，页码属性使用PageIndex，调用方从0开始传参。即第一页的话pageIndex=0，第二页pageIndex=1，et cetera.
毕竟这是团队项目，底层框架、技术预研、服务层逻辑、前端UI，大家有不同的分工。我想，即使是完全交给某一个人来做，迟早他也会乱的。因此，尤其是team leader，应该尽早在做code review时发现这些问题，并统一开发规范。这就完了吗？没有，接下来是…………………………………..………………………………….…………………………………..………………………………….………………………………..………………………………….………………………………..………………………………….………………………………..………………………………….………………………………..………………………………….……………………………..………………………………….………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….………………………………..…………………………………. …………………………………..………………………………….…………………………………..…………………………………………………………………..…………………………………. …………………………………..………………………………….…………………………………..…………………………………………………………………..…………………………………. …………………………………..………………………………….…………………………………..…………………………………………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….监控大家的执行情况。
跑题了，接着聊一点规范吧。在你的开发组的项目里，
l 就商品/产品的命名上，是否同时存在product和goods？
l 是否存在一些全局变量（在使用时才声明变量，这是个好习惯，全局作用域极易因使用不当而带来潜在风险）
l 调用别人接口得到list后，是不是不判断为null（有时还需判断其Count>0）就直接使用？（不要轻信别人的代码，即使他确信不会返回null）
l ……
继续，我的一点实践总结：
l 对于List对象的命名。通常以-List结尾，比如productList、orderList。另一种方式，对于名词，可以以其复数形式来命名。如products、orders，而对于idList，则最好不用ids。
l 我们目前的项目是一个B2B+B2C模式的电商交易系统，订单表名自然是喜闻乐见的orders。这个表同时存放这2种模式的交易数据，对于零售来说是零售订单，对于商家交易来说是采购单。Orders表与会员（普通用户和商家）的ER见下图。对于交易涉及到的双方，orders表里有2个字段CustomerId和ShopId。随着业务逻辑梳理、服务层逻辑代码的编写、客户端调用、需求微调所致迭代等工作的不断进行，发现买家卖家登录后对这2个属性赋值查看自己订单列表时，存在诸多不便，尤其是理解层面。目前，项目在逐步将这2个属性改为BuyerId和SellerId（同样的CustomerName改为BuyerName，ShopName改为SellerName）。
l 在我们项目里，商城一些推荐栏比如推荐商品，这个功能是由运营人员通过后台来设置的，这个列表的显示需要有排序，这时在领域模型里就要有这么一个显示序号的属性，我们起初命名成了ShowOrder，后来改成了DisplayNo，为了避免让大家联想到订单。
我很赞同我们项目组架构师的一句话：“架构要考虑成本和效率”。他在面试求职者时曾提问：“如何做到你的接口不需要用户借助说明文档就能理解?” 值得我们思考。
真的是有最佳实践的，
如webservice的wsdl。
再如public void CreateCache(int cacheSize)
传入的数据是bytes, KB, MB 还是GB？
改成public void CreateCache(int cacheSize_mb)
一目了然，并且会减少调用者传入错误数据的可能。
继续跑题，说下产品设计方面，在我们产品经理设计的商城页面里，其中，采购平台页面里有一个栏位叫最新上架：
在另一个一级分类频道页里，也有一个取数逻辑相同的栏位叫新品到货：
个人认为，全局角度来看的话，这2个栏位应该取相同的名字。难道同一个商城里你能有些页面称商品为商品而有些页面称商品为产品么？
BTW，老早就想写这篇博客了，总是找各种理由推脱。周二晚上下班和一同事一起乘公交回去，我告诉他我次日上班后就抽时间写一篇博客。谁知，到了周三中午我同事问我写了没有时，我却发现我由于工作忙给忘记了。——我借故忙给推脱了，直到现在，8月份的最后一个工作日。
说到忙，这段时间，精确的说，是有3个月了，是有些忙，倒是没少加班，每到周五晚又搭车80公里回家看孩子，每周一5点起大早又匆匆赶回来。为什么老回家？我家新添了两名小成员，我的双胞胎闺女，小飞飞和小扬扬，真是不知不觉，她们已经两个半月大了，这期间的每个日夜，妻子默默付出了很多。。。
当pageIndex遇上pageNo