一、 缘 起
- 在市场经济大环境下，如何缩短工期、降低成本，并提高开发效率？
- 开发上线后的软件，怎样最大限度降低维护成本，并提高IT企业投资回报率？
- 怎样迅速响应市场需求变化，为IT企业赢得持续的管理改善和商机？
面对传统开发方法和技术，IT 人员显得很无奈：团队成长问题，人员变更交接问题，没有一个稳定强大的、可扩展性强的软件开发框架，团队的精力就很容易被消耗在重复开发上，没有积累重用，更易造成时间浪费、财力浪费、消极影响严重。
IT 企业战略重点是做好某软件的应用规划和软件技术基础架构规划，为软件选择可靠的、能够支持企业成长的技术架构。迈普（MyPro）软件开发框架采用 Java 语言作为基础语言，面向对象式开发，具备组件重用性必要特性，能够支持各行业应用软件对技术的需求，可作为企业应用软件二次开发工具或应用平台集成管理框架。
1. 迈普（MyPro）框架简介
迈普（MyPro Web Development Framework）软件开发框架【简称 迈普（MyPro）】是一款基于 HTML5/JEE 环境架构的 B/S 结构（Browser/Server 结构）软件开发框架，用于快速开发自由、高效、稳定的 Web 2.0 应用软件，打造易上手、易开发、易维护的软件开发解决方案。 整个构建采用良好的 MVC 模式（模型-视图-控制器），确保每个功能模块分工更严谨、更高效。
迈普（MyPro） 软件开发框架可向 IT 企业或应用软件开者提供软件开发解决方案。
2. 开发动机
开发迈普（MyPro）之前也用过知名的开源框架，比如 Spring、Struts、Hibernate……虽然此类方案占据主流位置，但不能否认 SSH 配置复杂，而且臃肿、运行速度慢。迈普（MyPro）开发人员从 ASP/JSP/PHP 时代过来，觉得应该在80%情况下不需要繁杂的配置就能运行并且轻量快速，所以决定开发迈普（MyPro） 作为 SSH 的替代方案。
迈普（MyPro） 是基于约定优于配置的思想，框架会自动执行约定的或者被标注的函数，参数也是可变的；并且框架本身不依赖任何第三方jar包，不会发生框架依赖的第三方包和业务代码的依赖包产生冲突。
迈普（MyPro） 非常注重功能的实用性，对于平时不常用的功能不会添加到迈普（MyPro） 当中，这样可以避免像其他开源框架那样过于臃肿。同时我们认为保持代码的简洁非常重要，代码越少越容易阅读，修复 bug 也越容易。借用 C.A.R. Hoare 的名言：软件设计有两种方法：一种是尽可能地简单，这种设计明显没有什么缺陷；另一种是尽可能地复杂，这种设计没有明显的缺陷。
二、 框架特性
使用开发框架的一个很重要的原因就是降低开发和维护成本。以下则是迈普（MyPro）的愿景和目标。
1. 平台式集中管理
功能支持各种应用软件开发，利用 迈普（MyPro） 可以轻松快速的开发适合自个的众多应用软件
项目； 迈普（MyPro） 可定制多种模板以便支持包括手机在内的多种信息终端显示。更主要的是凡以 迈普（MyPro） 框架构建的应用软件项目均可灵活安装、卸载平滑过度。
2. 易学易用上手快
后端型：有 Java 基础知识、JavaBean、Servlet 开发经验即可马上进行企业级业务功能开发；二次开发方便快捷，系统基于自主研发的基于 J2EE 标准（Servlet & JSP 等）以及核心模式（MVC等）的高效框架，不引入过多无关技术概念，达到二次开发高效，维护方便的效果。
3. 多平台分布式部署支持
具备跨平台特性，可以运行于 Linux、Unix 及微软 Windows 操作系统环境下；
同时支持资源分布式部署，可将迈普（MyPro） 中多个资源模块分别部署于多个不同平台同时工作。
4. 多终端显示支持
终端显示的模板文件支持外库数据调用，采用 MVC 模式实现了程序与模板完全分离，只需制作不同终端显示模板即可达到良好用户体验效果； 同时支持向终端软件提供远程数据服务支持，可从服务端直接输出 JSON/XML 格式内容。
5. 扩展性敏捷高效
采用 Java 原生态语法机制，学习门槛低，只要有 Java 基础均可做开发。框架支持包类库开发、应用开发、模板解析开发、数据连接开发，强大灵活的接口机制，让你随心 DIY 自己的软件产品，以及应用软件项目开发。
实用型：内置应用软件基础模块(用户管理、用户组管理、权限管理、角色管理、管理员管理、静态生成、定时任务、邮件发送、短信发送等多个模块)，支持图片、动画、视频、附件上传，对图片支持缩略图、水印的生成操作；可单独配置、单独保存，只需修改上传配置文件即可。
6. 安全性严谨可靠
整个系统结构包含多种不同模块的检验判断，均可在配置文件中完成； 可设置允许访问、限制访问 IP 范围、可预防 Session 欺骗及 Cookie 欺骗、可阻止 XSS 侵入、可防范 SQL 注入攻击； 在默认的 UI 模板体系中，后台管理访问路径可配置更换，每个管理页面均可与权限点对点对接，以确保每个管理员的页面操作范围。加密采用盐值加密策略（不可逆转的生成算法，告别密码门）。
三、 关键名词解释
- 站点与栏目：本系统采用站点和栏目的概念对内容和信息进行划分规划管理。站点是系统的顶级划分节点，其包含的文本，图片，多媒体，文件等资源，以物理或业务处理逻辑方式划分在所属站点内，与其他站点独立。栏目则是按照信息发布所表现的类别特点进行内容划分。
- 模板：按照 HTML5 规范以及使用本系统提供的数据标签所编写的符合 J2EE 标准的 JSP 页面。
- 数据标签：编写页面过程中，页面和系统数据交互的渠道。
- 管理员用户：参与管理系统的本系统使用人员，附属于系统而非站点，可根据实际业务需求对其进行各站点管理权限的分配。
- 角色组织与机构：权限为用户在本系统中可执行的操作，角色为权限的集合，机构为现实单位组织的计算机意义划分，可控制角色的授权范围。
- 工作流：本系统发布信息的审核流程，由系统所定义的机构组织角色和用户参与，只有根据工作流定义的审核流程全部通过后，信息才可被发布。
四、 框架说明
按照典型的 MVC 模式分为控制器层、视图层和数据层。
迈普 OR/M 框架轻巧简单实用，是对传统 JDBC 数据库操作进行的二次封装，支持 Java 开发模型层常见设计：Entity+Dao+Service 结构；支持 SQL 原始拼装、SQL 原始传参式赋值和 Map 对象赋值。其中，SQL 操作部分支持变量定义，整个代码简洁直观，稍懂 SQL 就可以胜任，无过高学习成本。
1. 控制器层
（待补充……）
2. 视图层
（待补充……）
3. 数据层存储原理
在 Java 世界中，JDBC 是各大数据库供应商共同遵循的标准，数据库对于 JDBC 来说是完全透明的，数据库所有的结构信息都可以通过 JDBC 存取；迈普 OR/M 框架同数据库记录中的字段与字段值之间形成了对应关系。由于有了这两个基础，从而为实现对象关系映射技术提供了前提。 而使用 迈普 OR/M 框架，完全不需要大量的 bean 类，更不需要定义 XML 映射文件或者注入属性。其优点是很明显的。
迈普 OR/M 框架与传统对象关系映射技术，它们的目标基本一致，但实现的技术手段有着本质的不同。传统 OR/M 技术使用实体 Bean 或普通旧式 Java Bean（POJO）作为载体，实现数据存取。 因此，需要定义大量的实体 bean 或 Java Bean，实体 bean 或 Java bean 中还需要定义大量的属性，如果一个数据库表有上百个甚至数百个字段，定义这样的 bean，对于编程人员来说将是难以忍受的。 不仅如此，这到目前为止，ORM 还必须定义 XML 映射文件或者通过注入属性的方式找到 bean 的属性与字段之间的对应关系，这在物理上是对数据库的结构信息进行了重复定义，从而人为导致了软件工程文件量的急剧膨胀， 必然导致大量的人力财力的投入。即使使用代码生成技术，也是一件费力的事情。
而迈普 OR/M 框架认为，传统 OR/M 中定义 XML 映射文件或 bean 注入属性的做法是多余的。
一个典型的软件生命周期大致如此：刚完成的系统如同一个美少女，在客户的要求下，修改后，脸上开始长“青春痘”，几经修改后“痘痘”越来越多，后来成为“legacy”系统，最终成为不得不抛弃的“腐烂”的系统。设计师可能会为其辩解，而真正的原因是什么呢？真正的原因有四个：过于僵硬、过于脆弱、复用率低、黏度过高。过于僵硬是很难在一个系统里加入一个新的性能，哪怕是很小的都很难。如果用这种观点来考察 OR/M 工具，你会有什么想法呢？如果对一个字段进行了修改，不仅要改相应的业务处理代码，还要修改 XML 文件，可能还要修改一个 JavaBean，甚至一个 Java 接口。过于脆弱是与软件过于僵硬同时存在的，是软件系统在修改原有代码时过于脆弱。对一个地方的修改，往往会导致看上去没有什么关系的另一个地方发生故障……
XML 作为通用的信息交换媒介，成为 Web 服务器、EJB服 务器、数据库配置文件已经司空见惯，这样的应用确实需要，而且数量是有限的。然而用 XML 文件来描述关系数据库表的信息，在 Java 中，并不是必须的，因为一旦在数据库中定义了表后，这些相关信息完全可以通过 JDBC 来获取。更可怕的，在客观现实中，就整个行业来说，对数据库表的需求数量是无限的，如果都要用XML文件去描述会导致同样无限数量的 XML 文件。不仅如此，使用 OR/M 工具，可能还要定义无数的 JavaBean、无数的 Java 接口。如此无限重复定义基础信息，又怎样谈软件开发效率呢？使用 OR/M 工具不仅不能有效地提高系统的可维护性，也不能带来软件性能的提高，而且还不可避免的造成巨大的信息重复定义，它能带来的好处是十分有限的。这种不计成本的代码堆积，不仅带来的是软件难以维护，其所造成的时间、金钱的浪费可能是无法估量的，最终的结果，恐怕连软件的质量无法保证。这些都是《J2EE设计开发编程指南》作者指出 O/RM 利弊的原因吧。
性能上，相比Hibernate、iBatis、DBUtils等，JDBC的性能都超过它们。JDBC提供更底层更精细的数据访问策略，这是 Hibernate 等框架所不具备的。迈普 OR/M 基于 JDBC 构建。
迈普 OR/M 框架是为了简化 JBDC 编程的复杂性、提高 JDBC 数据库编程效率，而开发的一个通用的抽象级 JDBC 程序设计工具包。与其说它是一个映射工具，更不如说它是一个简化 JDBC 编程的通用的 API——它一旦在建立了与数据库的连接将动态提取相关数据库信息，来完成几乎与数据库相关的全部基本操作，而不需要任何 XML 之类的数据库表的描述文件，也不需要定义 JavaBean 或接口。但如果用 OR/M 工具完成以上几项任务却并不轻松。
迈普 OR/M 框架技术方案符合 DAO设计模式思想，核心类封装了与数据库插入、更新、删除、查询，相关的基本操作，并且实现了对查询结果集进行分页、筛选、排序、备份、获取子集的多种算法；有效地实现了数据库访问操作与业务逻辑的分离。与现有 DAO 之类设计模式技术相比，如 Hibernate 等，本方案并没有采用 XML 语言来配置对象和关系型数据之间的映射，取而代之的是实现 HashMap 与关系型数据之间的映射，免去了复杂的 XML 之类的数据库表的描述文件，是一个“一次写成，到处运行”的通用的抽象级简化 JDBC 编程的工具。因此，可以更简洁、更方便地实现对数据库操作。在 EJB、Application、Servlet、Applet 等应用中均可不受限制地方便使用。使用此项技术，可以大大提高数据库编程的效率，同时可以大大减轻数据库服务器数据流量的负担。同传统的数据库编程技术相比，使用迈普 OR/M 工具可以将数据库编程的效率提高数倍、甚至是数十倍。工程项目越复杂，数据库的字段越多就越能体现迈普 OR/M 工具所带来的灵活、高效。
关系数据映射技术的构思过程
之前我有过两年的 FoxBase 经历、那时对 Hibernate 一度产生了浓厚的兴趣，但用了后觉得挺麻烦。为什么要构思 HashMap 关系数据映射技术，那是因为我有了以前的经历，有了对比，所以对当时以 Hibernate 为代表的对象关系映射技术产生了强烈地质疑，回想以前 FoxBase 数据库编程，好简洁、好轻松。作为一种工具，在能够解决问题的前提下，减轻工作负担，才是值得称道的。ORM 把解决的问题复杂化了，导致软件工程文档急剧膨胀，软件的开发效率低，成本高。
使用 Hibernate 实现数据库编程，根本不比 JDBC 轻松。当时 Hibernate 受到了整个软件行业的吹捧，我觉得存在很大的盲目性。
总之，我始终认为 SQL 语言优于优于 Hibernate 的 HQL 语言，无论 Hibernate 的创建者还是使用者怎样的吹捧 HQL 如何如何的棒，但一个客观的事实是，SQL 语言是一种标准的操作数据库的语言，SQL 除了在 DBMS 中使用外，在 VB、Delphi、PHP、C/C++、Java 等高级语言中均可以使用，它是任何一个软件工作者都无法回避的，是必须掌握的一门基础性语言。
对于生成的结果，可以方便地生成 JSON/XML文件。迈普 OR/M 使用 Map 对象作为输入输出中数据的载体，其灵活性是无庸置疑的。
迈普 OR/M 使用的是 JDBC 事务，没有提供 JTA 分布式事务的支持，这是根据需求所决定。在 Jave 世界，真正使用 JTA 分布式事务的工程只是少数，而提供这种技术支持的产品相当成熟，如果用户需要使用 Java 分布式事务，建议使用 JPA2.x 等技术。请注意：JDBC 事务、JTA 事务是不能混合使用的，JTA 事务必须受 JavaEE 服务器支持，目前的 web 服务器均不支持 JTA 事务。当前主流的大型数据库服务器自身都具有分布式事务处理的能力。