本文共 5733 字，大约阅读时间需要 19 分钟。
第二章
对象的构成模型
对象由类来描述，类(Signature[对象的核心语义概括],Property[内部特征,状态],Method[行为])
JavaBean模式{
PO(Persistent Object)-持久化对象
BO(Business Object)-业务对象
VO(Value Object)-值对象
DTO(Data Transfer Object)-数据传输对象
FormBean-页面对象
}
上述的对象纷繁复杂，但本质都是运行在JavaBean(数据的存储和传输的载体)模式下对象的有效扩展或增强。
@Entity
@Proxy(lazy = true)
@Cache(usage = CacheConcurrencyStrategy.READ一WRITE)
public class User {
@ld
@GeneratedValue
private Integer id;
@Column
private String name；
@Column
private String password；
@Column
private String email；
//这里省略了所有的setter和getter方法
)
作者以Hibernate作为O/R Mapping映射工具时，一个典型的PO为例，说明JavaBean自身没有发生改变，只是引入了一些额外的编程元素(Annotation)对JavaBean进行了增强。
对象的关系模型
无状态对象：对象的方法所表达的行为特性并不依赖于对象的内部属性的状态。
1，引用
public class Book {
private String name;
private List<Author> authors;
}
2，继承(extends,implements)
3，关于对象建模
| 对象建模是一个很深刻的哲学问题，它将直接影响我们的编程模式。所以对干建模这 个问题，大家应该综合各家之言，并形成自己的观点。笔者在这里的观点是：对象建棋方 式首先是一个哲学问题，取决于设计者本身对于业务和技术的综合考虑。任何—种建模方式都不是绝对正确或者绝对错误的方式。我们所期待看到的对象建模的结果是提高程序的“可读性”、“可维护性”和“可扩展性”。一切建模方式都应该首先服务于这一基本的程序开发的最佳实践。 |
| 4，面向对象编程的核心内容是建立对象之间的关系模型 |
如何管理对象与对象之间的协作关系？(后续章节讨论)
5，框架的本质
什么是框架？框架从何而来？为什么要使用框架？
框架是一个jar包本质是对jdk的功能扩展；
框架式一组程序的集合，包含了一系列的最佳实践，作用是解决某个领域的问题。
总结：
| 只有解决问题才是所有框架的共同目标。框架的产生就是为了解决一个又一个在开发中所遇到的困境，不同的框架，只是为了解决不同领域的问题所以，对于广大程序员来 说，千万不要为了学习框架而学习框架，而是要为了解决问题而学习框架，这才是一个程 序员的正确学习之道。 |
* 了解下apache的commons-lang
最佳实践
没有一成不变的最佳实践，始终保证程序的可读性、可维护性和可扩展性；
简单是美；
减少依赖；
Web开发的基本模式
1，分层开发模式
表示层（Presentation Layer)——负责处理与界面交互相关的功能
业务层（Business Layer)—负责复杂的业务逻辑计算和判断
持久层（Persistent Layer)——负责将业务逻辑数据进行持久化存储
分层开发模式，逻辑上就是将职责分派到不同的对象上去执行的一种设计思想。对象的协作关系可以看做这一模式的理论依据。
职责分派，什么是职责？什么样的对象适合什么样的职责？
分层有无必要？分几层合适？
分层开发模式，对于大型企业应用或者产品级的应用程序开发是有着重要意义的；然而当一个应用程序足够小，并且需求的变更处于可控的范围之内时，我们对于分层开发模式的选择应该谨慎。
一切脱离了业务实际的架构设计都是虚幻的，分几层需要根据实际情况决定。
2，MVC模式
Model-数据模型,View-视图展现,Control-控制器
MVC模式-对应分层开发模式中的表示层。
程序时时有，概念心中留。只要MVC的理念在心中，无论程序怎么变都是万变不离其中。
3，MVC模式的困惑
通过以下四个对象可以很容易实现一个MVC模式的雏形
javabean(Model数据模型),
jsp（View对外交互）,
servlet（Control程序执行和控制）,
web.xml（URL Mapping请求转化）
那么为什么还需要框架呢？本身实现MVC似乎也并不复杂。
程序终究是一个动态的执行过程。一且程序开始运行，上面的方式实现的程序实现就会开始遭遇种种困境。这些困境主要来源于两个方面：其一，出于程序自身的可读性和可维护性考虑，需要通过重构来解决程序的复杂性困境。其二，出于业务扩展的需求，需要通过框架级别的功能增强来解决可扩展性困境。
问题1当浏览器发送一个Http请求，Web容器是如何接收这个请求并指定相应的Java 类来执行业务遣辑并返回处理结果的？
这个问题简称为URL Mapping问题。这个问题的本质实际上来源于Hup协议与Java程序之间的匹配和交互；
我们可以看到使用web.xml来表达URL Mapping关系遇到的困境：当系统变大，这种配置上的重复操作会让web.xml变得越来越大而难以维护。不仅如此, web.xml的配置也无法为URL Mapping建立起合适的规则引擎；
由此，解决URL Mapping问题的核心在于建立一套由Http协议中的URL表达式到 Java世界中类对象的规则匹配引擎。额外的，这种规则匹配最好比较灵活而简单又不失必要的可维护性。
| 问题2 Web应用是典型的“请求一响应”模式的应用，数据是如何顺利流转于浏览器和 Java世界之间的？面对Http协议与Java世界数据形式的不匹fc性，我们如何能够在流转 时做到数据类负的自动转化？ |
这个问越伴随着问题1而来，数据请求与数据返回相当千是基于“请求-响应”模式 的Web程序的输入和输出。数据的本质是存储于其中的信息，只不过数据在不同的地方有不同的表现形式。例如，在浏览器中，数据总是以字符串形式展现出来，表现出“弱类型” 的特征；在Java世界，数据则体现为一个个结构化的Java对象，表现出“强类型”的特征。于是，就需要有一个工具能够帮助我们解决在数据流转时的数据形式的相互转化。 我们可以看到Servlet中，我们要编写了额外的代码，把页面上传递过来的日期值转化为Java中的Date对象。在参数的数量和Java对象越来越复杂的情况下，这种额外的代码就会变成一种灾难，其至成为我们开发的主要瓶颈之一。 解决数据流转问题的方案是使用表达式引擎。将表达式引擎插入到程序逻辑执行之前，我们就能从复杂的对象转化中解放出来，从而进一步简化开发流程。
问题3 Web容器是一个典型的多线程环境，针对每个Http请求，Web容器的线程池会分 纪一个特定的线程进行处理•那么如何保证在多线程环境下，处理请求的Java类是线程 安全的对象？如何保证数据的流转和访问都是线程安全的？
这个问题与问越1 一样，也是Web开发中的核心问题之一，因为它涉及Web开发中 最为底层的处理机制问题。在上面的例子中，我们使用的是基干Servlet标准的方式进行 编程，扩展Servlet用于处理Http请求。然而恰恰就是这种编程模型是一种非线程安全 的编程模型，因为Servlet对象是一个非线程安全的对象。也就是说，如果我们在doPost 方法中访问Servlet中所定义的局部变量，就会产生线程安全问题（第4章会 重点介绍线程安全问题产生的来龙去脉）。
传统的表示层框架对干这个问题的处理方式是采用规避问題的方式。既然Servlet对 象不是一个线程安全的对象，那么我们就千脆禁止在Servlet对象的方法中访问Servlet对 象的内部变量。这种鸵鸟算法固然是一种有效的方案，但它却不是一种合理的方案。最致 命的一点是，它是一种非语法检査级别的禁止，因此也就无法从根本上杜绝程序员犯这样 的错误。
另外一种解决方案就是在整个请求周期中引入ThreadLocal模式，通过ThreadLocal 模式的使用，将整个过程的对象访问都线程安全化，彻底解决多线程环境下的数据访问问 题（有关ThreadLocal模式的方方面面，我们在后续章节中会详细介绍）。ThreadLocal模 式的引入对于Web层框架的影响是深远并且颠覆性的，因为它为框架摆脱Web容器的依 赖铺平了道路，意味着我们可以通过合理的设计，在脱离Servlet等Web容器元素的环境 中进行编程。
问题4 Controllor层作为MVC的核心控制器，如何能够在最大程度上支持功能点上的扩展？
问题4来源于我们对程序本身的自然属性（可读性和可扩展性）的需求。这一内在需 求实际上也驱动着我们着手在整个MVC的构架级别设计更为成熟有效的自扩展方案。
从一个更加宏观的角度来帮助我们理解这个问题，我们来举一个制药工厂生产药品的例子，一个工厂在进行批置生产时，总是会引入“生产线”的概念。生产线能够把整个制 药过程划分成若干道工序，当原材料经过每一道工序，最终就会成为一个可出厂销售的药 品。某一天，由于市场推广的原因，需要改变药品的包装，那么我们对这条生产线的要求 就是它能够改变“包装”这道工序的流程，更改成新的包装。
在上面的例子中，我们可以看到并没有一个“生产线”的槪念。这种情况下，我们口 后对于逻辑功能的扩展就变得困难重重。虽然我们发现，RegistrationServlet或许和其他所 有的Servlet有着非常类似的执行步骤：接收参数、进行类型转换、调用业务逻辑接口执 行逻辑、返回处理结果。然而我们却缺乏一条可以任意配置调度的生产线将这个过程规范 起来。
解决这个问题从直观上来讲似乎很容易：没有生产线，我们建一条生产线就行了。而 事实上，“造轮子”实在是一件费时费力的事情，因为我们要考虑的方面实在太多。这时 我们就不得不借鉴许多前辈的经验了，寻找某些事件定义的框架，遵循框架的定义规范来 进行编程将是我们解决这个问题的主要途径。
问题5 View层的表现形式总是多种多样的，随着Web开发技术的不断发展，MVC如何 在框架级别提供一种完全透明的方式来应对不同的视图表现形式？
这一问题是基于View (视图）技术的不断发展，造成传统的基于HTML的视图已经 不能满足所有的需求而提出的。当今，越来越多新的视图技术被用于Web开发中，例如， 模板技术、JSON数流、Stream数据流、Flash展现等等。
在上面的例子中，我们可以看到负责视图层跳转的RegistrationServlet是通过硬编码方式完成程序执行跳转的。这种方式不但无法支持多种新的视图技术，同时也无法使我们 从复杂的视图跳转的硬编码中释放出来。
解决这个问题的最有效途径是把不同的视图技术进行分类，针对不同的分类封装不同 的视图跳转逻辑，而最重要的一步是将这两者与之前我们所提到的生产线有机结合起来。
问题6 MVC模式虽然很直观地为我们规定了表示层的各种元素，但是如何通过某种机 制把这些元素有机整合在一起，从而成为一个整体呢?
这个问题非常宏观，却是我们不得不去面对的一个问题。MVC虽然在槪念上被规定 下来，在实现上却需要一个完整的机制来把这些元素都容纳在一起。通常情况下，我们往往把这种机制称之为配置元素。配置元素是构成程序的重要组成部分，它把各种形式的程序通过某种配置规则联系在一起。之前我们提到的URL Mapping实际上也属于配置规則 的一种，视图的跳转也是配置规则的一种。只有当这种配置规则被建立起来，MVC模式才能真正运作起来。
这一系列配置元素在框架内部往往被定义成统一的可以被框架识别的数据结构并在系统初始化的时候进行缓存。而这些被缓存了的对象，也成为主程序的控制流在MVC框架 中各个元素之间进行流转的依据。
如果从元素的表现形式上来看配置元素和控制流的关系，我们实际上可以看到整合过程的两个层面：数据结构和流程控制。所谓的框架，我们也只是在这两个层面上做文章， —方面规定好这些配置元素的定义，另一方面指定程序运转的流程，从而控制和整合散落在各处的表示层元素。
如何学习开源框架
最佳实践阅读、仔细阅读、反复闽读每个开源框架自带的Reference;实践框架自带的sample。
程序员的常见借口之一：英语水平跟不上;
程序员的常见借口之二：Reference太长;
最佳实践自己写一个sample项目亲身体验。
实践是检验真理的唯一标准。只有自己亲自动手去实践，才能说明你真正掌握了某种 技术，理解了某个框架的特性。在编写自己的sample项目时，大家可以针对不同的特性， 人为设置好业务场景（例如，使用“登录”作为一个基本的业务场景），在实践中不断地 重构你的代码，从而领悟框架开发中的最佳实践，提升自己的开发水平。
最佳实践带着问题调试（Debug)开源框架的源码。
在学习开源框架的源码时，笔者的建议是当程序运行在Debug模式的状态下，对源码 进行调试，在Debug的过程中，査看在开源框架的内部到底运行了哪些类，它们的执行顺 序是怎样的以及这些类中临时变量的执行状态。笔者坚决反对逐个package地去阅读源 码，这毫无意义。因为程序本身是一个整体，程序之所以成为程序，其本质在于它是动态 的、运行的。如果我们逐一去阅读源码，就相当于把一个完整的整体进行肢体分解，那么 我们将永远无法看到一个完整的动态执行过程。学习源码，最重要的一点在于抓住一个程 序在运行过程中某一时刻某个关键类的运行状态和最终状态，而这些都能通过调试源码来 实现，这才是阅读源码的最佳实践。
转载地址：http://mjbsi.baihongyu.com/