1.MVC模型
MVC是一种经典的设计模式，全名为Model-View-Controller，即模型-视图-控制器。
其中：
模型是用于封装数据的载体，例如，在Java中一般通过一个简单的POJO（Plain Ordinary Java Object）来表示，其本质是一个普通的Java Bean，包含一系列的成员变量及其getter/setter方法。没有从任何类继承、也没有实现任何接口，更没有被其它框架侵入的java对象。
（javaBean:是一种JAVA语言写成的可重用组件。JavaBean符合一定规范编写的Java类，不是一种技术，而是一种规范。大家针对这种规范，总结了很多开发技巧、工具函数。符合这种规范的类，可以被其它的程序员或者框架使用。它的方法命名，构造及行为必须符合特定的约定：
1、所有属性为private。
2、这个类必须有一个公共的缺省构造函数。即是提供无参数的构造器。
3、这个类的属性使用getter和setter来访问，其他方法遵从标准命名规范。
4、这个类应是可序列化的。实现serializable接口。
因为这些要求主要是靠约定而不是靠实现接口，所以许多开发者把JavaBean看作遵从特定命名约定的POJO。
POJO其实是比javabean更纯净的简单类或接口。POJO严格地遵守简单对象的概念，而一些JavaBean中往往会封装一些简单逻辑。pojo的格式是用于数据的临时传递，它只能装载数据， 作为数据存储的载体，而不具有业务逻辑处理的能力。而javabean虽然数据的获取与pojo一样，但是javabean当中可以有其它的方法。
DAO（data access objects）DAO是数据访问对象，DAO一般有接口和该接口的实现类，接口用于规范实现类。实现类一般用于操作数据库，如对数据库进行修改、添加、删除等操作，一般直接调用公共类DAO。
我们通过DAO将POJO持久化为PO，用PO组装出来VO、DTO。
总结下，我认为一个对象究竟是什么O要看具体环境，在不同的层、不同的应用场合，对象的身份也不一样，而且对象身份的转化也是很自然的。就像你对老婆来说就是老公，对父母来说就是子女。设计这些概念的初衷不是为了唬人而是为了更好的理解和处理各种逻辑，让大家能更好的去用面向对象的方式处理问题。
比如：我们一张表有100个字段，那么对应的PO就有100个属性。但是我们界面上只要显示10个字段，客户端用WEBservice来获取数据，没有必要把整个PO对象传递到客户端，这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO。
BO: POJO在业务层的体现，对于业务操作来说，更多的是从业务上来包装对象，如一个User的BO，可能包括name, age, sex, privilege, group等，这些属性在数据库中可能会在多张表中，因为每一张表对应一个PO，而我们的BO需要这些PO组合起来(或说重新拼装)才能成为业务上的一个完整对象。
EJB(Enterprise JavaBean): 我认为它是一组"功能"JavaBean的集合。上面说了JavaBean是实现了一种规范的Java对象。这里说EJB是一组JavaBean，的意思是这一组JavaBean组合起来实现了某个企业组的业务逻辑。这里的一组JavaBean不是乱组合的，它们要满足能实现某项业务功能的搭配。找个比方，对于一身穿着来说，包括一顶帽子，一件衣服，一条裤子，两只鞋。这穿着就是EJB，其它的就是一个JavaBean
SSH与EJB区别
EJB是一种javabean的组合规范，SSH是3个框架jar包的组合。
EJB本身是JavaEE的规范由容器厂商负责实现，也就是使用EJB，需要使用JavaEE服务器。而用SSH，直接用Web服务器， SSH中要解决的目标和EJB是一致的。EJB是大型的，SSH是轻量级的。
）
视图它更加偏重于展现，也就是说，视图决定了界面到底长什么样子，在Java中可通过JSP来充当视图，或者通过纯HTML的方式进行展现，而后者才是目前的主流。
模型和视图需要通过控制器来进行粘合，例如，用户发送一个HTTP请求，此时该请求首先会进入控制器，然后控制器去获取数据并将其封装为模型，最后将模型传递到视图中进行展现。
综上所述，MVC的交互过程如图1所示。
优点：让开发更加高效，让代码耦合度尽量减小，让应用程序各部分的职责更加清晰。
缺点：
每次请求必须经过“控制器->模型->视图”这个流程，用户才能看到最终的展现的界面，这个过程似乎有些复杂。
实际上视图是依赖于模型的，换句话说，如果没有模型，视图也无法呈现出最终的效果。
渲染视图的过程是在服务端来完成的，最终呈现给浏览器的是带有模型的视图页面，性能无法得到很好的优化。
优化：首先从浏览器发送AJAX请求，然后服务端接受该请求并返回JSON数据返回给浏览器，最后在浏览器中进行界面渲染。
改进后的MVC模式如图2所示。
也就是说，我们输入的是AJAX请求，输出的是JSON数据，市面上有这样的技术来实现这个功能吗？答案是REST。
如果将浏览器这一端视为前端，而服务器那一端视为后端的话，可以将以上改进后的MVC模式简化为以下前后端分离模式，如图3所示。
可见，有了REST服务，前端关注界面展现，后端关注业务逻辑，分工明确，职责清晰。
2.认识REST
REST是一种轻量级的Web服务，大家习惯将其称为RESTful Web Services，或简称REST服务REST本质上是使用URL来访问资源种方式。
众所周知，URL就是我们平常使用的请求地址了，其中包括两部分：请求方式与请求路径，比较常见的请求方式是GET与POST，但在REST中又提出了几种其它类型的请求方式，汇总起来有六种：GET、POST、PUT、DELETE、HEAD、OPTIONS。尤其是前四种，正好与CRUD（Create-Retrieve-Update-Delete，增删改查）四种操作相对应，例如，GET（查）、POST（增）、PUT（改）、DELETE（删），这正是REST与CRUD的异曲同工之妙！需要强调的是，REST是“面向资源”的，这里提到的资源，实际上就是我们常说的领域对象，在系统设计过程中，我们经常通过领域对象来进行数据建模。
REST是一个“无状态”的架构模式，因为在任何时候都可以由客户端发出请求到服务端，最终返回自己想要的数据，当前请求不会受到上次请求的影响。也就是说，服务端将内部资源发布REST服务，客户端通过URL来访问这些资源，这不就是SOA所提倡的“面向服务”的思想吗？所以，REST也被人们看做是一种“轻量级”的SOA实现技术，因此在企业级应用与互联网应用中都得到了广泛应用。
下面我们举几个例子对REST请求进行简单描述：
可见，请求路径相同，但请求方式不同，所代表的业务操作也不同，例如，/advertiser/1这个请求，带有GET、PUT、DELETE三种不同的请求方式，对应三种不同的业务操作。
虽然REST看起来还是很简单的，实际上我们往往需要提供一个REST框架，让其实现前后端分离架构，让开发人员将精力集中在业务上，而并非那些具体的技术细节。下面我们将使用Java技术来实现这个REST框架，整体框架会基于Spring进行开发。
3. REST框架
统一响应结构
使用REST框架实现前后端分离架构，我们需要首先确定返回的JSON响应结构是统一的，也就是说，每个REST请求将返回相同结构的JSON响应结构。不妨定义一个相对通用的JSON响应结构，其中包含两部分：元数据与返回值，其中，元数据表示操作是否成功与返回值消息等，返回值对应服务端方法所返回的数据。该JSON响应结构如下：
{
"meta": {
"success": true,
"message": "ok"
},
"data": ...
}
为了在框架中映射以上JSON响应结构，我们需要编写一个Response类与其对应：
publicclassResponse {
private static finalString OK ="ok";
private static finalString ERROR ="error";
private Meta meta;
private Object data;
public Response success() {
this.meta =newMeta(true, OK);
returnthis;
}
public Response success(Object data) {
this.meta =newMeta(true, OK);
this.data = data;
returnthis;
}
public Response failure() {
this.meta =newMeta(false, ERROR);
returnthis;
}
public Response failure(String message) {
this.meta =newMeta(false, message);
returnthis;
}
public Meta getMeta() {
returnmeta;
}
public Object getData() {
returndata;
}
public classMeta {
private boolean success;
private String message;
public Meta(booleansuccess) {
this.success = success;
}
public Meta(booleansuccess, String message) {
this.success = success;
this.message = message;
}
public booleanisSuccess() {
return success;
}
public String getMessage() {
return message;
}
}
}
Response类包括两类通用返回值消息：ok与error，还包括两个常用的操作方法：success( )与failure( )，通过一个内部类来展现元数据结构
实现对象序列化
什么是对象序列化？通过浏览器发送了一个普通的HTTP请求，该请求携带了一个JSON格式的参数，在服务端需要将该JSON参数转换为普通的Java对象，这个转换过程称为序列化。再比如，在服务端获取了数据，此时该数据是一个普通的Java对象，然后需要将这个Java对象转换为JSON字符串，并将其返回到浏览器中进行渲染，这个转换过程称为反序列化。不管是序列化还是反序列化，我们一般都称为序列化。
实际上，Spring MVC已经为我们提供了这类序列化特性，只需在Controller的方法参数中使用@RequestBody注解定义需要反序列化的参数即可，如以下代码片段：
@Controller
public class AdvertiserController {
@RequestMapping(value ="/advertiser", method = RequestMethod.POST)
public Response createAdvertiser(@RequestBody AdvertiserParam advertiserParam) {
...
}
}
若需要对Controller的方法返回值进行序列化，则需要在该返回值上使用@ResponseBody注解来定义，如以下代码片段：
@Controller
public class AdvertiserController {
@RequestMapping(value ="/advertiser/{id}", method = RequestMethod.GET)
public @ResponseBody Response getAdvertiser(@PathVariable("id") String advertiserId) {
...
}
}
当然，@ResponseBody注解也可以定义在类上，这样所有的方法都继承了该特性。由于经常会使用到@ResponseBody注解，所以Spring提供了一个名为@RestController的注解来取代以上的@Controller注解，这样我们就可以省略返回值前面的@ResponseBody注解了，但参数前面的@RequestBody注解是无法省略的。实际上，看看Spring中对应@RestController注解的源码便可知晓：
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Controller
@ResponseBody
public @interface RestController {
String value()default"";
}
可见，@RestController注解已经被@Controller与@ResponseBody注解定义过了，Spring框架会识别这类注解。需要注意的是，该特性在Spring 4.0中才引入。
因此，我们可将以上代码进行如下改写：
@RestController
public classAdvertiserController {
@RequestMapping(value ="/advertiser", method = RequestMethod.POST)
public Response createAdvertiser(@RequestBody AdvertiserParam advertiserParam) {
...
}
@RequestMapping(value ="/advertiser/{id}", method = RequestMethod.GET)
public Response getAdvertiser(@PathVariable("id") String advertiserId) {
...
}
}
除了使用注解来定义序列化行为以外，我们还需要使用Jackson来提供JSON的序列化操作，在Spring配置文件中只需添加以下配置即可：
若需要对Jackson的序列化行为进行定制，比如，排除值为空属性、进行缩进输出、将驼峰转为下划线、进行日期格式化等，这又如何实现呢？
首先，我们需要扩展Jackson提供的ObjectMapper类，代码如下：
public class CustomObjectMapper extends ObjectMapper {
privatebooleancamelCaseToLowerCaseWithUnderscores =false;
privateString dateFormatPattern;
publicvoidsetCamelCaseToLowerCaseWithUnderscores(booleancamelCaseToLowerCaseWithUnderscores) {
this.camelCaseToLowerCaseWithUnderscores = camelCaseToLowerCaseWithUnderscores;
}
publicvoidsetDateFormatPattern(String dateFormatPattern) {
this.dateFormatPattern = dateFormatPattern;
}
publicvoidinit() {
// 排除值为空属性
setSerializationInclusion(JsonInclude.Include.NON_NULL);
// 进行缩进输出
configure(SerializationFeature.INDENT_OUTPUT,true);
// 将驼峰转为下划线
if(camelCaseToLowerCaseWithUnderscores) {
setPropertyNamingStrategy(PropertyNamingStrategy.CAMEL_CASE_TO_LOWER_CASE_WITH_UNDERSCORES);
}
// 进行日期格式化
if(StringUtil.isNotEmpty(dateFormatPattern)) {
DateFormat dateFormat =newSimpleDateFormat(dateFormatPattern);
setDateFormat(dateFormat);
}
}
}
然后，将CustomObjectMapper注入到MappingJackson2HttpMessageConverter中，Spring配置如下：
处理异常行为
在Spring MVC中，我们可以使用AOP技术，编写一个全局的异常处理切面类，用它来统一处理所有的异常行为，在Spring 3.2中才开始提供。使用法很简单，只需定义一个类，并通过@ControllerAdvice注解将其标注即可，同时需要使用@ResponseBody注解表示返回值可序列化为JSON字符串。
可见，在ExceptionAdvice类中包含一系列的异常处理方法，每个方法都通过@ResponseStatus注解定义了响应状态码，此外还通过@ExceptionHandler注解指定了具体需要拦截的异常类。以上过程只是包含了一部分的异常情况，若需处理其它异常，可添加方法具体的方法。需要注意的是，在运行时从上往下依次调用每个异常处理方法，匹配当前异常类型是否与@ExceptionHandler注解所定义的异常相匹配，若匹配，则执行该方法，同时忽略后续所有的异常处理方法，最终会返回经JSON序列化后的Response对象。
支持参数验证
业务上需要确保AdvertiserParam对象的advertiserName属性必填，如何实现呢？
若将这类参数验证的代码写死在Controller中，势必会与正常的业务逻辑搅在一起，导致责任不够单一，违背于“单一责任原则”。建议将其参数验证行为从Controller中剥离出来，放到另外的类中，这里仅提供一个@Valid注解来定义AdvertiserParam参数，并在AdvertiserParam类中通过@NotEmpty注解来定义advertiserName属性
解决跨域问题
比如，前端应用为静态站点且部署在http://web.xxx.com域下，后端应用发布REST API并部署在http://api.xxx.com域下，如何使前端应用通过AJAX跨域访问后端应用呢？这需要使用到CORS技术来实现，这也是目前最好的解决方案了。
[CORS全称为Cross Origin Resource Sharing（跨域资源共享），服务端只需添加相关响应头信息，即可实现客户端发出AJAX跨域请求。]
CORS技术非常简单，易于实现，目前绝大多数浏览器均已支持该技术（IE8浏览器也支持了），服务端可通过任何编程语言来实现，只要能将CORS响应头写入response对象中即可。
提供安全机制
解决REST安全调用问题，可以做得很复杂，也可以做得特简单，可按照以下过程提供REST安全机制：
当用户登录成功后，在服务端生成一个token，并将其放入内存中（可放入JVM或Redis中），同时将该token返回到客户端。
在客户端中将返回的token写入cookie中，并且每次请求时都将token随请求头一起发送到服务端。
提供一个AOP切面，用于拦截所有的Controller方法，在切面中判断token的有效性。
当登出时，只需清理掉cookie中的token即可，服务端token可设置过期时间，使其自行移除。