键值对在架构设计里的应用.docx

键值对在架构设计里的应用架构文摘微信号 ArchDigest功能介绍 每天一篇架构领域重磅好文，涉及一线互联网公司的互联网应用架构、大数据、机器学习等各个热门领域。一、谈谈我对程序的理解　　作为程序员你对程序是如何理解的？写这篇文章的时候，我认真思考了下，发现我对程序的理解不是和教科书一样的，我每次听到程序二字我想到的只有两个东西：代码和数据，而每次写程序的时候也就是写代码操作数据的过程。　　做程序开发和做菜很像，数据就是食材，代码就是厨艺，做出的软件就是一道菜了，至于这个菜好不好吃，到底是看食材还是看厨艺了？呵呵，当我抛出这个问题的时候，我的第一反应是菜不好吃当然是手艺不好了，不知道其他童鞋是不是这么想的。认真想下，一道好菜一般都是二者必须兼备，当然不排除某一项突出也可以达到同样的效果，但这种情况毕竟不是大众化，而是属于少数精英的，做软件也是如此，代码与数据是不可偏废的。这里我要提的是数据。　　根据我的经验和知识（分类标准我一直想不太好，所以说是自己的经验和知识），我把数据分为两类：落地数据和不落地数据。1. 落地数据：就是被持久化的数据，这种数据一般放在硬盘或是其他的持久化存储设备里，例如：图片、系统日志、在页面上显示的数据以及保存在关系数据库里的数据等等，落地数据一定会有一个固定的载体，他们不会瞬时消失的。2. 不落地数据：一般指存储在内存或者是网络传输里的数据，这些数据是瞬时，使用完毕就会消失，例如：我们在浏览器发送给服务器的请求；从数据库读取出来的一直到页面展示前的数据等等。　　写过程序的人都知道，程序里对这两种类型数据操作是有很大的不同的。二、由JavaEE的MVC设计模式谈起　Java一个很重要的贡献就是推出了MVC设计模式，MVC其实应该按VCM顺序读最好。V及View，主要是前台展示的页面；C及Controller，控制层主要作用是接受前台页面数据，根据数据的不同调用后台不同的业务模型，同时业务模型处理好的数据也要发送到Controller，Controller再分配给相应的前台页面；M及Model，模型层专门负责操作业务模型。下图很好的表达了MVC的理念：随着MVC模式的发展，现在流行的架构：View（视图层）+Controller（也叫action，控制层）+Service（业务模型层）+DAO(数据访问对象层)+数据库的多层结构，如下图：?红线是用户的请求；蓝线是服务器响应用户的请求。红色和蓝线也代表各层数据传输的流向。不管是传统的MVC模式还是现在流行的多层架构，?各个逻辑层传输的数据都是不落地数据。在Java项目里，一般我们都是传输JavaBean，而这些JavaBean都是程序员根据实际业务需求自己定义的，例如下面一个典型的JavaBean：各个逻辑层传输JavaBean对象的观念一定会深入很多Java程序员的人心，当一个项目开始，程序员都会吭哧吭哧的创建JavaBean对象，比如数据库表映射的JavaBean，在struts1.2里还有页面表达对应的JavaBean，做了这么多年这样的JavaBean，现在我就思考，使用JavaBean真是最好的选择吗？ 三、Nojavabean我这里借用现在很流行的NoSQL的定义作为我文章第三部分的标题。JavaBean已经深入很多Java程序员心理，甚至是很多程序员的习惯，其实它真的那么好用吗?真的那么包治百病吗？其实不尽然，下面我要列举它的缺点：1. Javabean的文件太多。一个Java企业项目，都会使用ORM,将数据库映射为Java对象，一般一张表对应一个JavaBean，甚至有些特殊情况还会归并一些表做一个统一的JavaBean，如果这个系统有1000张表也就会有不少于1000个JavaBean，在原始的struts1.2里面还有和页面表单字段一一对应的JavaBean，大伙可以想象下，这些毫无技术含量的Java类也许会像病毒一样去繁殖。2. JavaBean会增强各层之间的耦合度。每个层里运算结束，业务数据大多会被封装成JavaBean对象，不同的业务封装的JavaBean是不同的，MVC本来就是为逻辑层解耦做的设计，而传输介质却是包含业务逻辑，如果碰到业务层级的修改，各个层之间都会有相应的结构性修改，增加了维护的成本。3. 我们至少会多维护一份数据字典。数据库里的某张表一个字段叫USER_NAME,那么到了JavaBean里可能就变成了userName，当然我们在ORM会有一个映射模型，但是随着数据一层层传递，离数据库越远的数据，数据的本质也就越模糊，特别会给新手产生一定误解，增加了软件开发和维护成本。4. 这个是缺点是我的在实际项目里碰到的一个难题，我还没把它总结成一个概括性的缺陷，但我相信会有童鞋碰到类似的问题。我在一个项目里做权限管理，