程序员过关斩将-- 喷一喷坑爹的面向UI编程

 ### 摒弃面向UI编程 为何喷起此次话题，因为前不久和我们首席架构师沟通，谈起程序设计问题，一不小心把UI扯进来，更把那些按照UI来编程的后台工程师也扯了进来。今天特意百度了一下（其实程序员应该去google一下，奈何需要FQ），确实没有面向UI编程这个概念在市面上流传，大家可以当我是首创吧。需要声明一点，这里喷的是服务器开发人员哦！！ 我是一个极具打抱不平的人，浪迹编程十几年，见过太多的程序员因为UI改了，而跟着改程序。当年菜菜一不小心踏入歧途的时候，每天看着《七天入门xxx》乐此不疲，猛烈的消化着书中“极具文化”的内容。然后看着“该死”的产品经理发过来的原型图，费劲脑汁把数据库设计的特别符合原型图，然后开心的干起CUAD，你看，编程就是如此简单！！ 而且当年觉得自己不可一世，可以进阶架构师了 >原来初生牛犊真的可以不怕虎，是因为虎厉害吗？不，是因为牛犊还太傻X 无论是产经经理，还是前端开发人员，更或者是后端开发人员或者DBA，一切的工作都是围绕业务开展的，产品经理首先是第一个消化并理解业务的人，有的产品经理自己还未消化业务就做出原型图，概念图脑图等等，这些产品经理其实才是该死的。当产品把业务正确的用UI表达出来之后，业务便传到了客户端人员，至于服务端代码编写人员如果按照UI来理解业务，甚至设计数据库表，那多半是掉坑里了 无论是客户端人员还是服务端人员，写代码之前首先第一要做的，而且也是最重要的就是消化业务内容，把业务消化了写起代码来，有时候会对那些将来有扩展性的地方情不自禁留出扩展点。业务有时候就是要做一件事的过程，数据的流向而已，整体把握了才能设计出可以掌控的系统。 ### 面向业务编程 其实上面说了这么多，都比较“抽象”，别人会说你写的什么JB玩意，骂归骂，但是不能侮辱我对技术的热爱~~~ 喷了那么多看一个原型，话说这个产品画的还是不错的  一个简单的发帖动态内容的展示，如此简单的需求，你的系统该如何设计呢？ ##### 错误1 根据UI的设计，很多人第一步就开始设计数据库对应UI 字段 | 介绍 ---|--- Id | 动态id PublishUserId | 发布人id PublishUserName | 发布人姓名 PublisherUserImg | 发布人头像 ..... | .... 很多人会这样设计，其中不乏有些高级程序员，我自认为这样是错误的，说说我的想法，欢迎你们来喷。这是一个简单的动态展示，仔细分析你会发现这个业务其实包含一些子业务：动态的发布人业务，动态内容业务，动态内容产生的外围业务（点赞，留言，收藏等），如果硬是对应到表设计，也应该包含这三部分内容。 >任何数据库设计都不应该一一对应UI，UI只是你设计的参考而已，只是很多情况下业务模型正好和UI对应而已 ##### 错误2 很多人把发布人的姓名，头像保存在了动态表，我认为这个还要看这个动态的定义，如果动态的发布人明确了不会随着发布人信息的修改而变动，这个确实应该一次性保存，如果反之，只存一个用户Id足以，这样还可以避免因为发布人修改信息而带来的同步数据问题，要知道数据一致性这块其实是很烦人的。 >不要让UI的显示内容，影响你的业务设计 ##### 错误3 动态的内容后续产生的数据（点赞，收藏，评论）这些业务在动态中都有量化，那这个具体的数据量化值很多人选择在动态表中添加对应的字段（点赞总量，收藏总量等等）。其实我不建议这样做，原因如下： 1. 如果新建了这些字段来保存，动态的每一次产生结果都需要更新对应的字段，同时还要保证这个值和详细列表的数据一致性，不能产生100条评论，但是评论列表只有99条的情况发生。 2. 如果将来又新加了一条新的业务，比如分享的数量，那是不是还要在加一个分享量的数据表字段呢？ 3. 如果你读过菜菜以前的文章，应该知道菜菜一贯的尿性，这种动态的东西最适合做缓存，无论你愿意与否。至于这些点赞总数等这些类似业务，仔细分析只不过是属于动态内容的后续业务，应该包含在整体业务之中，如果非要撸一行代码： ``` public class Topic { public int Id; public string Content; ... public int ThumbUpNumber: //点赞数量 public int CommentNumber; //评论数量 ... } ``` 需要注意一点：我以上代码代表的是业务对象，可不是对应的DB中的表哦，这个业务对象也是我们要缓存的对象，当新加一条评论或点赞的时候，只不过是缓存数据的+1操作而已，至于这个数据值的初始化，完全可以由详情表来提供，在真实的业务中，点赞或者评论的数据量很少到达万级别，所以对于select count（0）这个操作来说都不是问题，一旦初始化完成做了缓存，后续的增加数量完全在内存中完成。 >这里我想喷：任何业务数据库都不是架构设计的中心 ### 写在最后 一个业务的成败在于产品设计，一个系统设计的好坏，成败在于程序员，在业务正确的情况下，请先消化掉业务再开始设计系统，UI只是你消化业务的参考，UI只是你业务的具体可视化体现。