键值对在架构设计里的应用范本参考.docx

键值对在架构设计里的应用 1 一、谈谈我对程序的理解 作为程序员你对程序是如何理解的？写这篇文章的时候，我认真思考了下，发现我对程序的理解不是 和教科书一样的，我每次听到程序二字我想到的只有两个东西：代码和数据，而每次写程序的时候也就是 写代码操作数据的过程。 做程序开发和做菜很像，数据就是食材，代码就是厨艺，做出的软件就是一道菜了，至于这个菜好不 好吃，到底是看食材还是看厨艺了？呵呵，当我抛出这个问题的时候，我的第一反应是菜不好吃当然是手 艺不好了，不知道其他童鞋是不是这么想的。认真想下，一道好菜一般都是二者必须兼备，当然不排除某 一项突出也可以达到同样的效果，但这种情况毕竟不是大众化，而是属于少数精英的，做软件也是如此， 代码与数据是不可偏废的。这里我要提的是数据。 根据我的经验和知识 （分类标准我一直想不太好， 所以说是自己的经验和知识） ，我把数据分为两类： 落地数据和不落地数据。 1. 落地数据：就是被持久化的数据，这种数据一般放在硬盘或是其他的持久化存储设备里，例如：图片、 系统日志、 在页面上显示的数据以及保存在关系数据库里的数据等等， 落地数据一定会有一个固定的载体， 他们不会瞬时消失的。 2. 不落地数据： 一般指存储在内存或者是网络传输里的数据， 这些数据是瞬时， 使用完毕就会消失， 例如： 我们在浏览器发送给服务器的请求；从数据库读取出来的一直到页面展示前的数据等等。 写过程序的人都知道，程序里对这两种类型数据操作是有很大的不同的。 二、由 JavaEE 的 MVC 设计模式谈起 2 Java 一个很重要的贡献就是推出了 MVC 设计模式， MVC 其实应该按 VCM 顺序读最好。 V 及 View ， 主要是前台展示的页面； C 及 Controller ，控制层主要作用是接受前台页面数据，根据数据的不同调用后 台不同的业务模型，同时业务模型处理好的数据也要发送到 Controller ，Controller 再分配给相应的前台 页面； M 及 Model ，模型层专门负责操作业务模型。下图很好的表达了 MVC 的理念： 随着 MVC 模式的发展， 现在流行的架构： View （视图层） +Controller （也叫 action ，控制层） +Service （业务模型层） +DAO( 数据访问对象层 )+ 数据库的多层结构，如下图： 3 4 红线是用户的请求；蓝线是服务器响应用户的请求。红色和蓝线也代表各层数据传输的流向。 不管是传统的 MVC 模式还是现在流行的多层架构， 各个逻辑层传输的数据都是不落地数据。 在 Java 项目里，一般我们都是传输 JavaBean ，而这些 JavaBean 都是程序员根据实际业务需求自己定义 的，例如下面一个典型的 JavaBean ： 5 各个逻辑层传输 JavaBean 对象的观念一定会深入很多 Java 程序员的人心，当一个项目开始，程序员都 会吭哧吭哧的创建 JavaBean 对象，比如数据库表映射的 JavaBean ，在 struts1.2 里还有页面表达对应的 JavaBean ，做了这么多年这样的 JavaBean ，现在我就思考，使用 JavaBean 真是最好的选择吗？ 三、 Nojavabean 6 我这里借用现在很流行的 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 会有一个映射模型，但是随着数据一层层传