一副示意图的构思过程

俗话说得好，"一图胜千言"(A picture is better than a thousand words), 当你看到一幅好的示意图的时候，可否想过要产生这么一副图片背后的艰辛？！呵呵，今天上午折腾了"一上午"才弄出最后觉得还算满意的图片...


初稿第一版和第二版构思


初稿第三版和第四版构思


最终决定

评论

9 楼 fujohnwang 2008-03-31  

呵呵，等我把SpringMVC一章写完了你就会发现那两幅图的奥妙了，
其实我是为了简化概念，采用第一步先只关注处理流程中的主要角色，然后再添加附加角色的处理方式，至于可选以及默认配置，好像在图里面不好表达吧，呵呵，这些当然会在内容部分提及啦。

PS. 所谓忆苦思甜，那段所谓的"彪悍"的日子还是比较怀念的，呵呵，起码对本人来说是这个样子。

8 楼 tedeyang 2008-03-31  

fujohnwang 写道

tedeyang 写道

good！楼主追求完美的心态和我一样。
不过为了工作效率，该放手时还是要放手。图片确实具有极其丰富的表达能力，但也不需要完全摒弃文字。像第一幅图，适当加点文字说明就可以弥补构图的缺陷了，能省不少时间；而最后一幅图也有缺点，还无法表达spring mvc的完整概念。

不妨谈谈还缺什么概念才是你所指的完整表达的springMVC，呵呵
以免我误导人啊

我的意思就是大多数图形如果缺乏文字说明是较难清晰自我描述的。
我摘抄一段MVC的官方说明：

引用

当DispatcherServlet配置好以后，DispatcherServlet接收到与其对应的请求之时，处理就开始了。下面的列表描述了DispatcherServlet处理请求的全过程：

找到WebApplicationContext并将其绑定到请求的一个属性上，以便控制器和处理链上的其它处理器能使用WebApplicationContext。默认的属性名为DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE。

将本地化解析器（localResolver）绑定到请求上，这样使得处理链上的处理器在处理请求（准备数据、显示视图等等）时能进行本地化处理。若不使用本地化解析器，也不会有任何副作用，因此如果不需要本地化解析，忽略它就可以了。

将主题解析器绑定到请求上，这样视图可以决定使用哪个主题。如果你不需要主题，可以忽略它。

如果上传文件解析器被指定，Spring会检查每个接收到的请求是否存在上传文件，如果是，这个请求将被封装成MultipartHttpServletRequest以便被处理链中的其它处理器使用。（关于文件上传的更多内容请参考第 13.8.2 节 “使用MultipartResolver”。）

找到合适的处理器，执行和这个处理器相关的执行链（预处理器，后处理器，控制器），以便为视图准备模型数据。

如果模型数据被返回，就使用配置在WebApplicationContext中的视图解析器显示视图，否则视图不会被显示。有多种原因可以导致返回的数据模型为空，比如预处理器或后处理器可能截取了请求，这可能是出于安全原因，也可能是请求已经被处理过，没有必要再处理一次。

在请求处理过程中抛出的异常,可以被任何定义在WebApplicationContext中的异常解析器所获取。使用这些异常解析器，你可以在异常抛出时根据需要定义特定行为。

Spring的DispatcherServlet也支持返回Servlet API定义的last-modification-date。决定某个请求最后修改的日期很简单：DispatcherServlet会首先寻找一个合适的handler mapping，检查从中取得指定的处理器是否实现了LastModified接口，如果是，将调用long getLastModified(request)方法，并将结果返回给客户端。

引用

This servlet is very flexible: It can be used with just about any workflow, with the installation of the appropriate adapter classes. It offers the following functionality that distinguishes it from other request-driven web MVC frameworks:

• It is based around a JavaBeans configuration mechanism.
• It can use any HandlerMapping implementation - pre-built or provided as part of an application - to control the routing of requests to handler objects. Default is BeanNameUrlHandlerMapping. HandlerMapping objects can be defined as beans in the servlet's application context, implementing the HandlerMapping interface, overriding the default HandlerMapping if present. HandlerMappings can be given any bean name (they are tested by type).
• It can use any HandlerAdapter; this allows to use any handler interface. Default adapters are HttpRequestHandlerAdapter, SimpleControllerHandlerAdapter and ThrowawayControllerHandlerAdapter, for Spring's HttpRequestHandler, Controller and ThrowawayController interfaces, respectively. HandlerAdapter objects can be added as beans in the application context, overriding the default HandlerAdapters. Like HandlerMappings, HandlerAdapters can be given any bean name (they are tested by type).
• The dispatcher's exception resolution strategy can be specified via a HandlerExceptionResolver, for example mapping certain exceptions to error pages. Default is none. Additional HandlerExceptionResolvers can be added through the application context. HandlerExceptionResolver can be given any bean name (they are tested by type).
• Its view resolution strategy can be specified via a ViewResolver implementation, resolving symbolic view names into View objects. Default is InternalResourceViewResolver. ViewResolver objects can be added as beans in the application context, overriding the default ViewResolver. ViewResolvers can be given any bean name (they are tested by type).
• If a View or view name is not supplied by the user, then the configured RequestToViewNameTranslator will translate the current request into a view name. The corresponding bean name is "viewNameTranslator"; the default is DefaultRequestToViewNameTranslator.
• The dispatcher's strategy for resolving multipart requests is determined by a MultipartResolver implementation. Implementations for Jakarta Commons FileUpload and Jason Hunter's COS are included; the typical choise is CommonsMultipartResolver. The MultipartResolver bean name is "multipartResolver"; default is none.
• Its locale resolution strategy is determined by a LocaleResolver. Out-of-the-box implementations work via HTTP accept header, cookie, or session. The LocaleResolver bean name is "localeResolver"; default is AcceptHeaderLocaleResolver.
• Its theme resolution strategy is determined by a ThemeResolver. Implementations for a fixed theme and for cookie and session storage are included. The ThemeResolver bean name is "themeResolver"; default is FixedThemeResolver.

流程上有不少策略，窃以为仅凭借图不足以完整描述。
譬如spring的mvc处理流程中存在这很多可选和默认配置，这里没有体现。
还有中间那个大箭头是什么意思？两幅图的关系没能说明清楚。

不过既然在写书，那肯定是图文并茂。呵呵

ps：度假回来收到楼主的pm，顺便参观了楼主的blog。楼主有段时间过的生活那叫一个惨烈，真是很彪悍！呵呵，2004年我还在哈尔滨呢，还没回常州。

7 楼 fujohnwang 2008-03-28  

我素描功底不行，呵呵，怕画出来的东西有碍观瞻，hoho

6 楼 抛出异常的爱 2008-03-28  

下回先用纸与笔画下来
再用照片方式.就不会被MS告了.
PS:我喜欢纸笔画出来的东西

5 楼 laiseeme 2008-03-27  

A picture is better than a thousand words

4 楼 fujohnwang 2008-03-25  

henven 写道

用什么工具画的？漂亮啊

不好意思，用visio画的，用的是盗版，不要告诉微软哈，不然我可惨了 ：-）

3 楼 fujohnwang 2008-03-25  

tedeyang 写道

good！楼主追求完美的心态和我一样。
不过为了工作效率，该放手时还是要放手。图片确实具有极其丰富的表达能力，但也不需要完全摒弃文字。像第一幅图，适当加点文字说明就可以弥补构图的缺陷了，能省不少时间；而最后一幅图也有缺点，还无法表达spring mvc的完整概念。

不妨谈谈还缺什么概念才是你所指的完整表达的springMVC，呵呵
以免我误导人啊

2 楼 tedeyang 2008-03-25  

good！楼主追求完美的心态和我一样。
不过为了工作效率，该放手时还是要放手。图片确实具有极其丰富的表达能力，但也不需要完全摒弃文字。像第一幅图，适当加点文字说明就可以弥补构图的缺陷了，能省不少时间；而最后一幅图也有缺点，还无法表达spring mvc的完整概念。

1 楼 henven 2008-03-25  

用什么工具画的？漂亮啊