喷一喷坑爹的面向UI编程

摒弃面向UI编程

为何喷起此次话题,因为前不久和我们首席架构师沟通,谈起程序设计问题,一不小心把UI扯进来,更把那些按照UI来编程的后台工程师也扯了进来。今天特意百度了g K M m一下(其实程序员应该去google一下,奈何需要FQ),确实没有面向UI编程这个概念在市面上流传,大家可以当我是首创吧。需要声明一点,这里喷的是服务~ w v {器开发人员哦!!

我是一个极具打抱不[ 3 $平的人,浪迹编程十几年,见过太多的程序员因为UI改了,而跟着改程序。当年菜菜一不小心踏入歧途的时候,每天看着《七天入门xxx》乐此不疲,猛烈的消化着书中“极具文化”的内容。然后看着“该死”的产品经理发过来的原型图,费劲脑汁把数据库设计! V . $ ! P J的特别符合原型图,然后开心的干起CUAD,你看,编程就是如此简单!! 而且当年觉@ ` # z r H #得自己不可一世,可以进阶架构师了

原来初生牛犊真的可以不怕虎,是因为虎厉2 , p J 8害吗?不,是因为牛犊还太傻X

无论是产经经理,还是T W H前端开发人员,更或者是后端开发人员或者D= R c o sBA,一切的工作都是围绕业务开展的,产品经理首先是第一个消化Y L G + S W O (并理解业务的人,有的产品经理自己还未消化业务就做H 9 0出原型图,概念图脑图等等,这些产品经理其实才是该死的。当产品把业务正确的用UI表达出来之后,业务便: 3 E | U传到了客户端人员,至于服务端代码编写人员如果按照UI来理解业务,甚至设计数据库表,那多半是掉坑里了

无论是客户端人员还是服务端人员,写代码之前首先第一要做的,而且也是最重要的就是消化业务内容,把业务消化了写起代码来,有时候会对那些将来有扩展性的地方情不自禁留出扩展点。业务有时候就是要做一件事的过程,数据的流向而已,整体把握了才能设计出可以掌控的系统。

面向业务编程

其实上面说了这么多,都比较“抽象”,别人会说你写的什么JB玩意,骂归骂,但是不能侮- $ 3 ^ A ? X }辱我对技术的热爱~~~

喷了那么多看一个原型,话说这个产品画的还是不错的

一个简单[ { $ [ o的发帖动态内容的展示,如此简单的需求,你的系统该如何设计呢?

错误1

根据UI的设计,很x r @ ^ U 9 ^ $多人第一步就D W | a开始设计数据库对应UI

字段 介绍
Id 动态id
PublishUserId 发布人id
PublishUserName 发布人姓名
PublisherUserImg 发布人头像
..... ....

很多人会这样设计,其中不乏有些高级程序员,我n 3 5 { W C % R G自认为这样是错误的,说说我的想法,欢迎你g ) x们来喷。这是一个简单的动态展S a 3 ( L _ X示,仔细分析你会发现这个业务其实包含一些子业务:动态的l | $ K @ a ! 4发布人业务,动态内容业务,动态内容产生的外围业务(点赞,留言,收藏等),如果硬是对| [ c K / @应到表设计,也应该包含! i - M m e . #这三部分内容。

任何数据库设计都不应该一一对应UI,UI只是你设计的参考而已,只是很多情况下业务模型正好和UI对应而已

错误2

很多人把发布人的姓名,头像保存在了动态表,我认为这个还要看这个动态的定义,如果动态的发布人s D M明确了不会随着t p G Z R T B发布人信息的修改而变动,这个确% @ Z o U g . -实应该一次性保存,= H s Q 3如果反$ * J X w ` u之,只存一个用户Id足以,这样还可以避免因为发布人修7 n _ r改信息而带来的同步数据问题,要知道数据一致性这块其实是很烦人的。

不要让UI的显示内容,影响你的业务设计

错误3

动态的内容后续产生的数据(点赞,收藏,评论)这些业务在动态中都有量化,那这个具体的数据量化L + d ^ ; | V( } v P 3很多人选择在动态表中p u 5 A {添加对应的` E $ 5 j Z Z字段(点赞总量,收藏总量等等)。其实我不建议这样做,原因如下:

  1. 如果新建了这些字段来保存,动态的w : X x O L & !每一次产生结果都需要更新对应的字段,同时还要保证这个值和详细列表的数据一致性,不能产生100条评论,但是评论列4 S F n表只有99条的情况发生。
  2. 如果将来又新加了一条新的业务,比如分享的数量,那是不是还要在加一个分享量的数据表字段呢?
  3. ) x Y c _果你读过菜菜以前的文章,应该知道菜菜一贯的尿性,这种动态的东西最1 B h适合做缓存,无论你愿意与否。至于这些点赞d ; x j D H K s总数等这些类似业务,仔细分析只不过是属于动态内容的后续业务I * c ] B !,应该包含在整体业务之中,如果非要撸一行代码:
    public class Topic
    {
    public int Id;
    public string ConH 0 F c } E vtent;
    ...
    public int ThY c I u , ZumbUpNumber: //点赞数量
    pg r [ublic int CommentNumber; //评论数量
    ...
    }

    需要注意一点:我以上代码代表的是业务对象,可不是对应的DB中的表哦,这个业务对象也是我们要缓存的对象,当新加一条评论或点赞的时候,只不过是缓存数据的+1操作而已,至于这个数据值的初始化,完全可以由详情表来提供,在真实的业务中,点赞或者评论的数据量很少到达万级别,所以对于select count(0)这个操作来说都不是问题,一旦初始化完成做了缓存,后续的增加数量完全在内存中完成。

这里我想喷:任何业务数据库都不是架构设计的中心

O F c U f在最后

一个业务的成败在于产品设计,一个系统设计的好坏,成败在于C F . p i I P程序员,在业务正g L M r | S确的情况下,请先消化掉业务再开始设计系统,UI只是你消化业务的参考,UI只是你业务的具体可视化体现。

更多精彩文章

  • 分布式大并发系列
  • 架构设计系列
  • 趣学算法和数据结构系列
  • 设计模式系列