struts+mybatis联合开发中数据的共享
过去的时间中，支撑开发的话题一直都是CRUD，虽然形式多样，但无非就这四个操作。由于没有涉及到业务，基本上也就都是些简单技术的使用。虽然技术都是简单的，没有设计模式，没有复杂逻辑，没有业务逻辑，但由于是框架封装，数据在其中的流动和各个地方的存在形式依然需要好好记录。
先画张图：
这里的整理只是已知的部分，还有很多细节没有体现。更靠谱的说法是，这是张思维导图。
首先看简单的部分，中间的service层。
由于service层的代码结构，或者是数据结构都是根据需求不停改变，所以，（在已知的情况中）没有一个好的框架对这一层进行好的封装。所以数据流动也更容易看见，毕竟都是在自己写的代码中，数据存在方式也是java中经典的数据存储方式，最常见的是封装在类中，这也是迎合OO思想的表现。当然，也会有放进特殊数据结构中的做法，但对于OO来说，这些数据结构也是类（当然，如果这么说是在用抽象的思想解决实际问题，没有意义。） 。
实际的来看，数据最多情况下放在了自己定义的类中，包括VO,PO,DAO等。
PO：持久对象，是持久层使用的对象。目前使用PO对数据库查询条件进行过封装，这个对象使用的意义在于，将数据库查询语句中需要的数据装在一个对象中，这样调用java中执行sql语句的方法时，只需要向参数中传入该对象即可，避免出现参数过多的情况。
DAO：数据访问对象。主要是用对象的思维来对数据查询进行封装，其中包含的主要是对数据的不同操作的抽象，并在其中提供实现数据操作的方法。通过DAO，可以实现数据的真实查询。
VO：数据对象。主要是用面向对象的方式封装一个数据块，其中包括对数据进行描述的POJO（简单java类型）对象，在类中被看作是字段，这些字段如果没有get或set方法，在web应用中几乎没有什么用处。当他们获得了自己的getter或setter的时候，这些字段被称作“属性”。属性是相对于javabean而言的。javabean中可以包含多种不同的POJO类型。当形成javabean的时候，在整个项目中的数据流动就有了基础。
虽然在service层提到了javabean，但是数据的数据封装并不是在这里形成的。真实的数据存在于“持久层”中，数据的封装也是在这里形成的。
现在来看持久层。
从命名就可以看出，这一层是将数据永久保存起来的地方。数据永久保存的方式就在于把数据写进掉电可存储的硬件中，对于个人计算机来讲，就是硬盘。但是数据不是随便谁都可以去管理的，因此需要一个数据管理的工具。同时，数据如果是零散的也没有意义，需要一个有序的数据存储方式（数据结构），这些数据存储方式管理和数据管理（数据导入，建立数学模型等等），通过“数据库”来实现。
既然是有序的来实现数据存储，就必定有一套规则来进行描述。数据库中有自己的描述方式，而java中有另一种描述方式。想要让java中的数据能够很好的放进数据库中，需要用到ORM（对象关系映射）。
想要实现这套规则，并为实现这套规则建立恰当的实现环境（数据库连接池，数据库连接，对象拆装，数据封装等等），并不容易，但同样，每次要做的操作又很相似。为此，出现了一系列框架，这里用的是Mybatis框架。
框架使用的配置文件包括， 数据库连接池配置，数据库JDBC配置，mapper配置。
数据连接池配置：Mybatis用来建议的配置连接池的文件，一旦配置文件成功引用，框架将自动创建连接池，与数据库保持长期连接并管理数据连接资源。
数据库JDBC配置：JDBC配置。JSBC是Mybatis框架依赖的数据库连接技术，配置中包含有数据库位置，JDBC核心类引用以及数据库连接的账号和密码。
mapper配置：这个配置文件中，写的全是sql语句，同时，该配置文件在需要的时候，还要用来指定数据封装的格式。对于没有配置封装格式的数据，Mybatis将实现自动封装，方法是，利用反射从指定的类中去找到属性，对属性（或字段）进行赋值。此处，需要用来封装数据的类的字段或属性名和数据库中列的名字相对应。 （框架约定，遵循该规则的情况下，不需要对数据进行更多配置）
至此，数据的获得得到了保障。从统一的数据源中获得数据也按照我们需要的格式进行了数据模型的表达。
数据从持久层中获得并成功封装以后，通过方法返回值、对象使用或者静态变量使用等方式，服务层也可以获得这些 数据，并进行进一步处理。处理结束以后，数据继续通过与持久层相同的方式，向展示层的后台代码中流动。
展示层：
展示层只做一件事情，就是展示数据。这也是结果看起来相对不那么枯燥，但其实也比较麻烦的一个地方。
首先，要知道的是，除去展示的前段代码，包括JSP,HTML等等，剩下的部分都是写在Java中的代码，也就是跑在应用服务器中的代码， 算作是后台代码。由于后台代码和前台代码有物理上分开（后台代码在服务器中，前台代码被浏览器解释）的特点，数据流动需要经过一些转换。在不涉及底层的情况下，可以认为，struts2的值栈充当了数据中转的机制。（底层实现方式，可以猜想为，通过http协议，将数据进行某种格式放在http请求或响应中，在网络环境中传输。对于前端来说，数据被浏览器通过http协议解析以后，拼凑成完整的文件，并对不同的文件按照自己的格式解析出来，再通过某种编程规范，将数据重新拼凑，形成一长段有价值的数据流。这段数据流被浏览器按照国际规范以及自己浏览器的独有风格以及客户配置约束，进行一系列复杂的编译，最终变成了另一种有意义的数据形式，放进计算机相应的硬件中，最终通过计算机硬件进行展示。对于后台，同样需要对http协议指定格式的数据进行解析，这一步发生在JVM中，解析以后的数据按照我们事先在代码中约定的方式进行封装以后就可以被程序猿使用了。）
对于值栈，其实就是提供了数据在不同物理位置，但是相同表现形式的可能。按照编程中透明化的要求，对于后台开发程序猿而言，值栈就是可以被后台和前台都认识的一种特殊的数据存储。 值栈中有两部分，分别是ValueStackContents和StackContext。
ValueStackContent是值栈中数值存储的位置。其中包含的所有栈行都可以看作是值栈中封装的一个个数据类，不同的行就是这个数据类的不同实例对象。 对于前端代码而言，使用struts提供的标签，直接通过数据的别名可以对这些数据进行操作。对于后端代码而言，只要在struts2中提供了这些数据对应的getter或setter，就可以按照使用类的方式对数据进行使用。
StackContext运行上下文。值栈中用来保存上下文数据的位置，其中通过Map的形式对数据进行表述，每条数据都对应自己的一个键，前端代码通过OGNL表达式对数据进行引用，后端代码通过对map进行操作对数据进行读写
（ActionContext.getContext().get(String key); OR ActionContext.getContext().put(String key,Object value);）。
至此，数据在struts2中（展示层）中的存储和使用已经结束。综合从服务层的数据流动，数据完成了从数据库中的提取，服务层的处理和转发，到达了展示层，按照五花八门的方式展示出来。
对于基本的web应用而言，已经完成了功能。
