Douyu0.6.1 源码分析 之 MVC篇

继 ZHH2009 从09年11月发布 Douyu 的第一个版本后，至到今年6月已经发布 Douyu 的[url="http://www.iteye.com/topic/1066808"]第二个版本[/url]了。其很多方面都有突破性的设计思路和实现方式，如异步 Action、View中读取Controller 中的本地变量、基于 javac 的动态编译、动态代码生成等等之类。正如作者 ZHH2009 所说，先不说该框架的实际发展及今后具体的应用前景如何，但是其不超过1500行的代码实现还是很值得大家去学习的。
对于 Douyu 的学习，我将从以下三个方面来进行入手。
[list]
[*][b]MVC 篇[/b]: 也就是本文所需要讲的。主要分析其 MVC 实现及请求处理流程等。
[*][b]javac 篇[/b]: 在 Douyu第二个版本中作者提到了其最炫的功能。在 View 中直接访问 Action 中的本地变量，Modle注入等，所以我将从源码分析该实现方式。并且会结合其"无需打包、部署，无需重启Servlet容器"的实现原理进行分析。
[*][b]异步Acton篇[/b]：将结合 Tomcat7.0 及 Servlet3.0 对Douyu的异步Action的实现机制进行分析。
[/list] [i]当然，如果你觉Douyu的哪些地方还可以值得学习分析的欢迎评论中补充。[/i]


[b][size=small]源码分析[/size][/b]
首先是当服务器启动时，初始化ControllerFilter ，调用 init 方法，主要用于初始化一些参数信息、ResourceLoader 实例及 视图配置信息：

	
public void init(FilterConfig filterConfig) throws ServletException {
	//------加载基础配置信息-----
	config.appName = servletContext.getContextPath();
	//编译编码
	config.javacEncoding = filterConfig.getInitParameter("javacEncoding"); 
	// 源文件目录，默认为 WEB-INF/src 目录
	config.srcDir = filterConfig.getInitParameter("srcDir"); 
	//编译的class文件路径，默认为 WEB-INF/classes
	config.classesDir = filterConfig.getInitParameter("classesDir"); 

	//------初始化视图配置信息-----
	//其配置格式为 视图处理提供类=视图扩展名
	//如:org.douyu.plugins.velocity.VelocityViewManagerProvider=vm;
	String vmpConfig = filterConfig.getInitParameter("viewManagerProviderConfig");
	if (vmpConfig == null)
		vmpConfig = viewManagerProviderConfig;
	config.setViewManagerProviderConfig(vmpConfig);

	//------初始化自定义的 ClassLoader 类-----
	// 以当前 ClassLoader 作为父 Loader，并根据配置信息创建 ResourceLoader 实例。这里采用 Holder模式 设计。
	holder = ResourceLoader.newHolder(config, getClass().getClassLoader());
}

[url=http://badqiu.iteye.com/blog/696983]关于Holder模式介绍[/url]

当发起请求时，如访问 http://127.0.0.1:8080/douyu-demo/HelloWorld.soCool，其 HelloWord 类的代码如下：

@Controller
public class HelloWorld {
	public void soCool(ViewManager v) {
		// do something.....             
		v.out("hello.jsp");
	}
}

当请求该 URL 时，则先进入 ControllerFilter.doFilter，其主要代码如下：

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
	String path = null;
	//异步 Action 相关
	if (request.getAttribute("javax.servlet.include.request_uri") != null)
		path = request.getAttribute("javax.servlet.include.request_uri").toString();
	// 非异步请求，获取当前请求的 URI 路径
	if (path == null)
		path = hsr.getRequestURI(); //path = hsr.getServletPath();


	//第一步：从URL 中获截取出调用的 Controller 类名(包括包名) 及 调用的方法名--
	//path格式: /packageName/controllerClassName.actionName
	if (path.startsWith("/"))
		path = path.substring(1);
	String controllerClassName = path;
	String actionName = null;
	int dotPos = path.indexOf('.');//谷歌浏览器(Chrome)不支持'|'字符，所以用'."分隔类名和action名
	if (dotPos >= 0) {
		actionName = path.substring(dotPos + 1).trim();
		controllerClassName = path.substring(0, dotPos);
	}
	controllerClassName = controllerClassName.replace('/', '.');
	//##执行到这时，该 actionName 为 soCool，controllerClassName 为 HelloWord


	//第二步：为指定的 Controller 加载对应的 Context 实例，具体请往下看对 loadContextClassResource 的分析
	StringWriter sw = new StringWriter();
	PrintWriter javacOut = new PrintWriter(sw);
	ClassResource cr = null;
	try {
		cr = holder.get().loadContextClassResource(controllerClassName, javacOut);
	} catch (JavacException e) {
		printJavacMessage(sw.toString(), response, e);
		return;
	}
}

通过 ResourceLoader 类加载器动态加载指定 Controller 对应的 AbstractContext 实现类，由于当首次请求 HelloController 时，其所对应的 AbstractContext 子类并不存在，于是便调用 javac 动态生成及编译其 AbstractContext 实现类。另外，如果是开发模式，在每次修改 Controller 类代码后，其 ResourceLoader 便会重新生成编码 Context 类及Controller类，从而实现修改代码后无须重启Server。

	public ClassResource loadContextClassResource(String controllerClassName, PrintWriter out) throws JavacException {
		// Controler 类所对应的AbstractContext实现类名, SUFFIX为 $DOUYU
		String contextClassName = controllerClassName + SUFFIX;
		// 从缓存中获取 context 类的 Class 
		ClassResource resource = classResourceCache.get(contextClassName);
		if (resource == null) {
			// 根据对应  controller 类加载对应 context 类		
			resource = loadContextClassResource(controllerClassName, contextClassName, out);
			if (resource != null) { // 将 context class resource 加入缓存
				classResourceCache.put(contextClassName, resource);
			}
		}
		if (resource != null && config.isDevMode) {
			// 如果修改过 controller 代码，将重新编译controller，并生成重新生成及编译其context类
			if (classResourceModified(out)) { 
				return copy().loadContextClassResource(controllerClassName, out);
			}
		}
		return resource;
	}

当调用 loadContextClassResource 时，首先直接根据 contextClassName 在 classpath 中找 controller的 java 文件，再调用 javac 将其编译，然后再去找该 controller 对应的 context 类，如果没有找到则根据 controller 类调用 javac 动态生成对应的 context 类代码，并将其编译。然后再使用 loadClassResource 来加载编译后的 context class 实例. 代码如下所示：
[code]
private ClassResource loadContextClassResource(String controllerClassName, String contextClassName, PrintWriter out) {
//1：首先根据 context 类名加载 class 对象，当首次请求controller 时，因为其对应的 context java和class文件并没有生成，所以这里可能为 Null
//带有SUFFIX后缀的类(以下简称:context类)，无需加载java源文件
ClassResource context = loadClassResource(contextClassName, false);

//!?? 这里直接判断不是开发模式就 Return 了，应该算不算是一个 Bug?
//if(context != null && !config.isDevModel) 这样才合理吧?
if (!config.isDevMode)
return context;

//2：加载 controller 的 class 对象，并找到 controller 类的源码，如果源码不存在则直接 return null。当首次请求 controller 时，其 class 文件并不存在，则调用 javac 编译其 controller 类。
//带有@Controller标注的类(以下简称:controller类)
//注意:事先并不知道controllerClassName是否是一个controller类，
//所以先假定它是controller类，
//当编译这个假想的controller类后，如果得不到对应的context类，
//那么就返回错误(比如返回404 或 返回400(Bad request)
ClassResource controller = loadClassResource(controllerClassName, true);

//3.1：context及controller都未找到，直接返回 null
if (context == null && controller == null) {
return null;
} else { //找到controller类或context类其中之一，或两者都找到了

//3.2：controller类找不到(对应的java源文件和class文件都找不到)
//这可能是由于误删除引起的，所以不管context类是否存在都无意义了，
//因为context类总是要引用controller类的.
if (controller == null) {
return null;
}

//3.3: 找到了controler类，但是其对应的 context 类未找到
//这通常是第一次请求controller类，此时服务器需要尝试编译它，并生成对应的context类
else if (controller != null && context == null) {
//未找到controller类的java源文件
//!?? 不知道为什么没找到 Controller 的源码就直接Return Null了，通常正式环境下可能都不存在 源文件的。估计是生成Context时需要解析 Controller 的源码 ?
if (controller.sourceFile == null) {
return null;
} else {
// 调用 javac 编译 controller，并动态生成及编译 context 类
javac.compile(out, controller.sourceFile);
//生成及编译之后及重新调用该方法加载 context 类
//如果这里加载为Null, 则有可能不是效的controller类
return loadClassResource(contextClassName, false);
}
} else { //3.4： context 和 controller 都找到了,直接返回context
return context;
}
}
}
[/code]至此，已经完成了 Context 类的加载。当首次请求完之后，则可以看到 WEB-INF/classes 中生成三个文件：
[img]http://dl.iteye.com/upload/attachment/529233/f7c7b987-4391-3935-a18d-07d9901efabf.png[/img]
其中的 HelloController.class 为一开始自己写的 Controller 类，其HelloWorld$DOUYU.java 及 HelloWorld$DOUYU.class 为该 Controller 对应的 Context 类。至于 Context 中的代码及作用在下面会进行分析。另外，关于 Douyu 如何调用javac实现自动生成 Context 的代码，其具体分析会在下篇文章中，也就是上面说的 javac 篇。有兴趣的可以去看看: com.sun.tools.javac.processing.ControllerProcessor 代码。
到这里，值的一提的是，虽然已经完成 Context 代码生成及编译，但是这里最终返回的是 ClassResource 对象，该对象通过 Class<?> loadClass 变量存储其 Context 的 Class 实例。于是，这便意味着需要在运行时加载 Context 的class字节码，为其生成 Class 对象。
Douyu 对动态 Class 加载，主要通过 org.douyu.core.ResourceLoader.findClassOrClassResource(String name, boolean resolve, boolean findJavaSourceFile) 方法实现。如果你了解 ClassLoader 机制话，你并不会陌生其实现机制，并且该方法的注释也非常详细。


[color=green][b]第三步：到这步为止，其 Context 、Controller都已经生成并编译完成，并且已经获取 Context 的 Class 实例。继续回到 org.douyu.mvc.ControllerFilter.doFilter 的代码分析。这里先是获取 Context 实例，调用其中的 executAction 执行 Controller 中的方法。 [/b][/color]

		// 在上面 第二步 中的代码通过 ResourceLoader 中的 loadContextClassResource 加载到 Controller 所对应的 Context 类，其 cr 为返回的ClassResource实现，其中存储着 Context 的 Class 实例。
		if (cr != null) {
			AbstractContext ac = null;
			try {
				// 创建 Context 实例，也就是这里的 HelloWord$DOUYU 类的实例
				ac = (AbstractContext) cr.loadedClass.newInstance();
				ac.init(config, controllerClassName, servletContext, hsr, (HttpServletResponse) response);
				// 执行 Controller 中的方法，这里也就是 soCool 方法
				ac.executeAction(actionName);

				printJavacMessage(sw.toString(), response, null);
			} catch (Exception e) {
				throw new ServletException(e);
			} finally {
				if (ac != null)
					ac.free();
			}
		} else {
			chain.doFilter(request, response);
		}

可以看到，上面Filter 中代码从来都没有调用过 Controller 中的方法，也就是这里的 HelloController.soCool方法，而调用的是 Context 类的 executeAction 然后传入需要调用的方法，也就是这里的 HelloController$DOUYU.executeAction 方法。
OK，那接着看第四步对 Context 的代码的分析。

[color=green][b]第四步： 以下类为在首次请求 /HelloController 时，会自动根据 HelloConroller 中的代码生成对应的Context 类代码： [/b][/color]

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.douyu.mvc.AbstractContext;

public class HelloWorld$DOUYU extends AbstractContext
{
  // 包含当前 Context 类所对应的 Controller 类实例。可见 Douyu  中的 Controller 是多线程单实例滴...
  // 但是当前这个类(Context)是多实例的，因为其 actionName、Request、Reponse等都 是全局变量.
  private static HelloWorld _c = new HelloWorld();


  protected void executeAction() throws Exception
  {

    if (this.actionName == null) this.actionName = "index";
    // 在 Controller 中有一个 soCool 的方法，于是这里便生成了一个if判断  
    if (this.actionName.equals("soCool")) {
      checkHttpMethods(new String[] { "GET", "POST" });
      // 调用 Controller 中的方法          
      _c.soCool(this);
    }
    // 这里的 if判断，是在生成该类代码时，从获取 HelloWord 中的所有方法方法名，如果 HelloWord 这个 Controller 中有多少方法，则生成 else if 根据 actionName 调用具体的 Controller 方法。
   // 不过当 Controller 的方法及参数较多的时候，该类生成的代码极其难看，不过考虑到该类并不需要维护，所以可以理解，只不过执行效率上是否所有影响？这个还需要做进一步探研
    // 至于这些代码是如何生成的，将在下篇文章会专门分析 JAVAC 的相关代码。
    else {
      this.response.sendError(404, this.request.getRequestURI());
    }
  }
}

Ok, 至于，已经完成从 请求至执行 Controller 中的方法代码分析，接下来最后一步便是关于视图的处理。

[color=green][b]第五步：在 Controller 中的代码 v.out("hello.jsp"); 进行视图熏染，其Context会根据视图的扩展名调用相应的视图处理器，如以下是 JSP 的视图处理器的 out 实现：[/b][/color]

@Override
	public void out(String viewFileName) {
		try {
			douyuContext.getHttpServletRequest().getRequestDispatcher(viewFileName).include(douyuContext.getHttpServletRequest(),
					douyuContext.getHttpServletResponse());
		} catch (Throwable t) {
			throw new ViewException(t);
		}
	}

之所以这里使用 JSP 的 include 而不是 forward，其目的之一是，作者所说的：
[quote]3. 支持Velocity、FreeMaker，集成其他模板引擎也是非常简单，多种模板引擎可以在同一个应用中同时使用。[/quote]
另外，对于视图中的变量处理，同样会在 javac 文章进行分析。
其Douyu对 视图处理是整个框架不错的设计地方之一，很大程度上解决 View 、Model、Servlet、 Controller 之间的耦合度，还提供了 View 扩展的API，对于增加新的视图实现也极其简单。 并且对视图管理类的创建采用了 [url=http://www.cnblogs.com/webabcd/archive/2007/01/22/626479.aspx]Provider 设计模式[/url]，从而可以同一类视图，支持多种处理模式。

目前该框好象没有对 Session 及 Application 作用域进行考虑，应该需要结合 AbstarctContext 设计，不过目前对于框架本身的设计，解决这个也不是什么问题。

OK，至此已经完成了Douyu 整个 MVC 请求的处理流程的代码分析，其分析程度还较浅。如果觉得有什么问题或想讨论该框架的设计，欢迎下面评论进行讨论。因目前还在对Douyu源码进行Debug，所以将下一文章将会结合 javac 实现更深一步对 Douyu 进行分析。