放弃面向UI的编程为什么开始这个话题，因为前不久跟我们的首席架构师沟通，谈了编程的问题，一不小心把UI带进去了，还把那些根据编写UI的后台工程师也参与其中。今天百度了一下（其实程序员应该去Google，但是需要FQ），面向UI编程的概念在市场上确实不流传。你可以认为我是第一个。需要声明的是，这里的喷子是服务器开发者！！我是一个很冤枉的人。自己编程十几年了，见过太多程序员因为UI改了而改程序。当年菜菜不小心误入歧途，每天都看不厌《七天入门xxx》，埋头消化书中“极度文化”的内容。然后，看着“该死的”产品经理发来的原型图，我努力设计了适合原型图的数据库，然后高高兴兴的上手了CUAD。你看，编程就是这么简单！！而且当时觉得自己立于不败之地，可以晋级架构师了。原来初生牛犊不怕虎。是因为老虎厉害吗？不是，是小牛还是太笨了X无论是生产经理、前端开发人员，还是后端开发人员、DBA，一切工作都是围绕业务展开的，产品经理是第一位的消化理解对于业务人员来说，有的产品经理在自己消化业务之前先做原型、概念图、脑图等。这些产品经理其实是该死的。当产品用UI正确表达业务后，业务传递给客户人员。而服务端的代码编写者，如果按照UI理解业务，甚至设计数据库表，很可能会掉坑里。不管是客户端人员还是服务端人员，在写代码之前首先要做的也是最重要的就是消化业务内容，消化业务再写代码，有时候忍不住要给那些预留扩展点将来会扩展的地方。有时候业务就是做一件事的过程，只是数据的流转。只有把握整体，才能设计出可控的系统。其实面向业务的编程上面说了这么多，还是比较“抽象”的。别人会说你写什么JB的东西，他们会骂你，但是你不能侮辱我对技术的热爱~~~喷了这么多看到一个样机，说这个产品很不错。它是发布动态内容的简单显示。这么简单的需求，你的系统应该怎么设计呢？误区一根据UI设计，很多人第一步就开始设计数据库对应的UI字段。IntroductionIddynamicidPublishUserIdPublisheridPublishUserNamePublishernamePublisherUserImgPublisheravatar...很多人会这样设计，其中不乏一些资深程序员，我觉得这样是不对的，说说我的想法，欢迎大家喷。这是一个简单的动态显示。仔细分析你会发现，这个业务其实包括了一些子业务：动态发布商业务、动态内容业务、动态内容产生的周边业务（点赞、评论、收藏等）。说到餐桌设计，这三部分也应该包括在内。任何数据库设计都不应该和UI一一对应。用户界面只是您设计的参考。在很多情况下，业务模型只是对应于UI。错误2很多人把发布者的名字和头像保存在动态表中。我认为这也取决于这个动态的定义。如果动态发布者清楚它不会随着发布者信息的修改而改变，这确实应该一次性保存。人修改信息导致的同步数据的问题，要知道数据一致性其实是很烦人的。不要让UI的显示内容影响你的业务设计失误3动态内容产生的后续数据（点赞、收藏、评论）这些业务在动态中是量化的，所以很多人选择使用具体的量化值动态中的数据在表格中添加相应的字段（总点赞数、总收藏数等）。事实上，我不建议这样做。原因如下：如果这些字段是新创建保存的，每次生成动态结果都需要更新对应的字段。同时要保证这个值和明细表的数据一致性，不能产生100条评论。,但评论列表只有99条。如果以后增加新的业务，比如股数，是不是需要增加股数的数据表字段？如果你看过菜菜之前的文章，应该知道菜菜的一贯小便最适合做缓存，不管你愿不愿意。至于像总点赞数这些类似的业务，仔细分析，也只是后续业务，属于动态内容，应该纳入整体业务。如果非要写一行代码：publicclassTopic{publicintId;公共字符串内容；...publicintThumbUpNumber://点赞数publicintCommentNumber;//Numberofcomments...}需要注意一点：我上面的代码表示的是一个业务对象，而不是对应DB中的一个表。这个业务对象也是我们要缓存的对象，在添加新的评论之类的时候，只是对缓存数据的+1操作。至于这个数据值的初始化，可以由明细表来提供。实际业务中，点击赞或评论的数据量很少能达到10000个级别，所以对于selectcount(0)操作来说不是问题。一旦初始化完成并缓存起来，后续增加的数量就完全在内存中完成了。在这里我要喷一下：任何业务数据库都不是架构设计的中心。写在最后一个。企业的成败在于产品设计。一个系统设计的成败在于程序员。当业务正确时，请先消化业务再开始设计系统，UI只是你消化业务的一个参考，UI只是你业务的具体可视化。更多精彩文章分布式并发系列架构设计系列趣味学习算法与数据结构系列设计模式系列
