【转载】如何写一个框架：步骤（上）

时间 2019-11-12

标签转载如何一个框架步骤繁體版

原文原文链接

说明：做者也没写过什么框架，只是分享一些本身的理解，抛砖引玉罢了。若是你写过一些框架可能会产生一些共鸣欢迎讨论，若是你正在写或正打算写一个框架可能会给你一些启发。本文觉得较长可能会分多个篇博客来写，如今能想到的是主要分为步骤、模式两部分。若是你以为好，按一个推荐举手之劳让更多的人能够看到。html

步骤

定位

所谓定位就是回答几个问题，我出于什么目的要写一个框架，个人这个框架是干什么的，有什么特性适用于什么场景，个人这个框架的用户对象是谁，他们会怎么使用，框架由谁维护未来怎么发展等等。前端

若是你打算写框架，那么确定内心已经有一个初步的定位，好比它是一个缓存框架、Web MVC框架、IOC框架、ORM/数据访问框架、RPC框架或是一个用于Web开发的全栈式框架。
是否要重复造轮子？除非是练手项目，通常咱们是有了解决不了问题的时候才会考虑不使用既有的成熟的框架而重复造轮子的，这个时候须要列出新框架主要但愿解决什么问题。有关是否应该重复造轮子的话题讨论了不少，个人建议是在把问题列清后进行简单的研究看看是否能够经过扩展示有的框架来解决这个问题。通常而言大部分红熟的框架都有必定的扩展和内部组件的替换能力，能够解决大部分技术问题，但在以下状况下咱们可能不得不本身去写一个框架，好比即便经过扩展也没法知足技术需求、安全缘由、须要更高的生产力、须要让框架和公司内部的流程更好地进行适配、开源的普适框架没法知足性能需求、二次开发的成本高于从新开发的成本等等。
主打轻量级？轻量级是不少人打算本身写一个新框架的缘由，但我们要明白，大部分项目在一开始的时候其实都是轻量级的，随着框架的用户愈来愈多，它一定须要知足各类奇怪的需求，在通过了无数次迭代以后，框架的主线流程就会多不少扩展点、检测点，这样框架势必变得愈来愈重（从框架的入口到框架的工做结束的方法调用层次愈来愈多，势必框架也就愈来愈慢），若是你打算把框架定位于一个轻量级的框架的话，那么在从此的迭代过程当中须要进行一些权衡，在心中有坚决的轻量级的理念的同时不断作性能测试来确保框架的轻量，不然随着时间的发展框架可能会愈来愈重进而偏离了开始的定位。
特性？若是你打算写一个框架，而且只有轻量级这一个理由的话，你或许应该再为本身的框架想一些新特性，就像作一个产品同样，若是找不出两个以上的亮点，那么这个产品不太可能成功，好比你的新框架能够是一个零配置的框架，能够是一个前端开发也能用的后端框架。
其它？通常来讲框架是给程序员使用的，咱们要考虑框架使用的频度是怎么样的，这可能决定的框架的性能需求和稳定性需求。还有，须要考虑框架未来怎么发展，是但愿走开源路线仍是商业路线。固然，这些问题也能够留到框架有一个大体的结构后再去考虑。

咱们来为本文模拟一个场景，假设咱们以为现有的Spring MVC等框架开发起来效率有点低，打算重复造轮子，对于新框架的定位是一个给Java程序员使用的轻量级的、零配置的、易用的、易扩展的Web MVC框架。程序员

调研

虽然到这里你已经决定去写一个框架了，可是在着手写以前仍是至少建议评估一下市面上的相似（成熟）框架。须要作的是通读这些框架的文档以及阅读一些源码，这么作有几个目的：正则表达式

经过分析现有框架的功能，能够制定出一个新框架要实现的功能列表。
经过分析现有框架的问题，总结出新框架须要避免的东西和改善的地方。
经过阅读现有框架的源码，帮助本身理清框架的主线流程为整体设计作铺垫（后面整体设计部分会更多谈到）。
若是能充分理解现有的框架，那么你就是站在巨人的肩膀上写框架，不然极可能就是在井底造轮子。

新开发一个框架的好处是没有兼容历史版本的包袱，可是责任也一样重大，由于若是对于一开始的定位或设计工做没有作好的话，未来若是要对格局进行改变就会有巨大的向前兼容的包袱（除非你的框架没有在任何正式项目中使用），兼容意味着框架可能会愈来愈重，可能会愈来愈难看，阅读至少一到两个开源实现，作好充分的调研工做可使你避免犯大错。数据库

假设咱们评估了一些主流框架后已经很明确，咱们的MVC框架是一个Java平台的、基于Servlet的轻量级的Web MVC框架，主要的理念是约定优于配置，高内聚大于低耦合，提供主流Web MVC框架的大部分功能，而且易用方面有所创新，新特性体包括：编程

起手零配置，整体上约定因为配置，即便须要扩展配置也支持经过代码和配置文件两种方式进行配置。
除了Servlet以外不依赖其它类库，支持经过插件方式和诸如Spring等框架进行整合。
更优化的项目结构，不须要按照传统的Java Web项目结构那样来分离代码和WEB-INF，视图能够和代码在一块儿，阅读代码更便利。
拦截器和框架自己更紧密，提供Action、Controller和Global三个级别的"拦截器"（或者说过滤器）。
丰富的Action的返回值，返回的能够是视图、能够是重定向、能够是文件、能够是字符串、能够是Json数据，能够是Javascript代码等等。
支持针对测试环境自动生成测试的视图模型数据，以便前端和后端能够同时开发项目。
支持在开发的时候自动生成路由信息、模型绑定、异常处理等配置的信息页面和调试页面，方便开发和调试。
提供一套通用的控件模版，使得，而且支持多种模版引擎，好比Jsp、Velocity、Freemarker、Mustache等等。

嗯，看上去挺诱人的，这是一个不错的开端，若是你要写的框架本身都不以为想用的话，那么别人就更不会有兴趣来尝试使用你的框架了。 json

解决难点

之因此把解决难点放在开搞以前是由于，若是实现这个框架的某些特性，甚至说实现这个框架的主流程有一些核心问题难以解决，那么就要考虑对框架的特性进行调整，甚至取消框架的开发计划了。有的时候咱们在用A平台的时候发现一个很好用的框架，但愿把这个框架移植到B平台，这个想法是好的，但之因此在这之前这么多年没有人这么干过是由于这个平台的限制压根不可能实现这样的东西。好比咱们要实现一个MVC框架，势必须要依赖平台提供的反射特性，若是你的语言平台压根就没有运行时反射这个功能，那么这就是一个很是难以解决的难点。又好比咱们在某个平台实现一个相似于.NET平台Linq2Sql的数据访问框架，但若是这个目标平台的开发语言并不像C#那样提供了类型推断、匿名类型、Lambda表达式、扩展方法的话那么因为语法的限制你写出来的框架在使用的时候是没法像.NET平台Linq2Sql那样优雅的，这就违背了实现框架的主要目的，实现新的框架也就变得意义不大了。后端

对于咱们要实现的MVC框架貌似不存在什么根本性的没法解决的问题，毕竟在Java平台已经有不少能够参考的例子了。若是框架的实现整体上没什么问题的话，就须要逐一评估框架的这些新特性是否能够解决。建议对于每个难点特性作一个原型项目来证实可行，以避免在框架实现到一半的时候发现有没法解决的问题就比较尴尬了。设计模式

分析一下，貌似咱们要实现的这8大特性只有第1点要研究一下，看看如何免配置经过让代码方式让咱们的Web MVC框架能够和Servlet进行整合，若是没法实现的话，咱们可能就须要把第1点特性从零配置改成一分钟快速配置了。缓存

开搞

首先须要给本身框架取一个名字，取名要考虑到易读、易写、易记，也须要尽可能避免和市面上其它产品的名字重复，还有就是最好不要起一个侮辱其它同类框架的名字以避免引发公愤。
若是未来打算把项目搞大的话，能够提早注册一下项目的相关域名，毕竟如今域名也便宜，避免到时候项目名和域名差距很大，或项目的.com或.org域名对应了一个什么不太和谐的网站这就尴尬了。
而后就是找一个地方来托管本身的代码，若是一开始不但愿公开代码的话，最好除了本地源代码仓库还有一个异地的仓库以避免磁盘损坏致使抱憾终身，固然若是不怕出丑的话也能够在起步的时候就使用Github等网站来托管本身的代码。

整体设计

对于整体设计个人建议是一开始不必定须要写什么设计文档画什么类图，由于可能一开始的时候没法造成这么具体的概念，咱们能够直接从代码开始作第一步。框架的使用者通常而言仍是开发人员，抛开框架的内在的实现不说，框架的API设计的好坏取决于两个方面。对于普通开发人员而言就是使用层面的API是否易于使用，拿咱们的MVC框架举例来讲：

最基本的，搭建一个HelloWorld项目，声明一个Controller和Action，配置一个路由规则让Get方法的请求能够解析到这个Action，能够输出HelloWorld文字，怎么实现？
若是要实现从Cookie以及表单中获取相关数据绑定到Action的参数里面，怎么实现？
若是要配置一个Action在调用前须要判断权限，在调用后须要记录日志，怎么实现？

咱们这里说的API，它不必定全都是方法调用的API，广义上来讲咱们认为框架提供的接入层的使用均可以认为是API，因此上面的一些功能均可以认为是MVC框架的API。

框架除了提供基本的功能，还要提供必定程度的扩展功能，使得一些复杂的项目可以在某些方面对框架进行加强以适应各类需求，好比：

个人Action是否能够返回图片验证码？
个人Action的参数绑定是否能够从Memcached中获取数据？
若是出现异常，可否在开发的时候显示具体的错误信息，在正式环境显示友好的错误页面而且记录错误信息到数据库？

通常而言若是要实现这样的功能就须要本身实现框架公开的一些类或接口，而后把本身的实现"注册"到框架中，让框架能够在某个时候去使用这些新的实现。这就须要框架的设计者来考虑应该以怎么样的友好形式公开出去哪些内容，使得之后的扩展实如今自由度以及最少实现上的平衡，同时要兼顾外来的实现不破坏框架已有的结构。

要想清楚这些不是一件容易的事情，因此在框架的设计阶段彻底能够使用从上到下的方式进行设计。也就是不去考虑框架怎么实现，而是以一个使用者的身份来写一个框架的示例网站，API怎么简单怎么舒服就怎么设计，只从使用者的角度来考虑问题。对于相关用到的类，直接写一个空的类（能用接口的尽可能用接口，你的目的只是经过编译而不是能运行起来），让程序能够经过编译就能够了。你能够从框架的普通使用开始写这样一个示例网站，而后再写各类扩展应用，在此期间你可能会用到框架内部的20个类，这些类就是框架的接入类，在你的示例网站经过编译的那刹那，其实你已经实现了框架的接入层的设计。

这里值得一说的是API的设计蕴含了很是多的学问以及经验，要在目标平台设计一套合理易用的API首先须要对目标平台足够了解，每个平台都有一些约定俗成的规范，若是设计的API能符合这些规范那么开发人员会更容易接受这个框架，此外还有一些建议：

之因此咱们把API的设计先行，而不是让框架的设计先行是由于这样咱们更容易设计出好用的API，做为框架的实现者，咱们每每会进行一些妥协，咱们可能会为了在框架内部DRY而设计出一套丑陋的API让框架的使用者去作一些重复的工做；咱们也可能会由于想让框架变得更松耦合强迫框架的使用者去使用到框架的一些内部API去初始化框架的组件。若是框架不是易用的，那么框架的内部设计的再合理又有什么意义？
尽可能少暴露一些框架内部的类名吧，对于框架的使用者来讲，你的框架对他一点都不熟悉，若是要上手你的框架须要学习一到两个类尚可接受，若是要使用到十几个类会头晕脑胀的，即便你的框架有很是多的功能以及配置，能够考虑提供一个入口类，好比建立一个ConfigCenter类做为入口，让使用者能够仅仅探索这个类即可对框架进行全部的配置。
一个好的框架是可让使用者少犯错误的，框架的设计者务必要考虑到，框架的使用者没有这个业务来按照框架的最佳实践来作，因此在设计API的时候，若是你但愿API的使用者必定要按照某个方式来作的话，能够考虑设置一个简便的重载来加载默认的最合理的使用方式而不是要求使用者来为你的方法初始一些什么依赖，同时也能够在API内部作一些检测，若是发现开发人员可能会犯错进行一些提示或抛出异常。好的框架无需过多的文档，它能够在开发人员用的时候告知它哪里错了，最佳实践是什么，即使他们真的错了也能以默认的更合理的方式来弥补这个错误。
建议全部的API都有一套统一的规范，好比入口都叫 XXXCenter或XXXManager，而不是叫XXXCenter、YYYManager和ZZZService。API每每须要进行迭代和改良的，在首个版本中把好名字用掉也不必定是一个好办法，最好仍是给本身的框架各类API的名字留一点余地，这样之后万一须要升级换代不至于太牵强。

下一步工做就是把项目中那些空的类按照功能进行划分。目的很简单，就是让你的框架的100个类或接口可以按照功能进行拆分和归类，这样别人一打开你的框架就能够立刻知道你的框架分为哪几个主要部分，而不是在100个类中晕眩；还有由于一旦在你的框架有使用者后你再要为API相关的那些类调整包就比困难了，即便你在建立框架的时候以为个人框架就那么十几个类无需进行过多的分类，可是在未来框架变大又发现当初设计的不合理，没法进行结构调整就会变得很痛苦。所以这个工做仍是至关重要的，对于大多数框架来讲，能够有几种切蛋糕的方式：

分层。我以为框架和应用程序同样，也须要进行分层。传统的应用程序咱们分为表现层、逻辑层和数据访问层，相似的对于不少框架也能够进行横向的层次划分。要分层的缘由是咱们的框架要处理的问题是基于多层抽象的，就像若是没有OSI七层模型，要让一个HTTP应用去直接处理网络信号是不合理的也是不利于重用的。举一个例子，若是咱们要写一个基于Socket的RPC的框架，咱们须要处理方法的代理以及序列化，以及序列化数据的传输，这彻底是两个层面的问题，前者偏向于应用层，后者偏向于网络层，咱们彻底有理由把咱们的框架分为两个层面的项目（至少是两个包），rpc.core和rpc.socket，前者不关心网络实现来处理全部RPC 的功能，后者不关心RPC来处理全部的Socket功能，在未来即便咱们要淘汰咱们的RPC的协议了，咱们也能够重用rpc.socket项目，由于它和 RPC的实现没有任何关系，它关注的只是socket层面的东西。
横切。刚才说的分层是横向的分割，横切是纵向的分割（横切是跨多个模块的意思，不是横向来切的意思）。其实横切关注点就是诸如日志、配置、缓存、AOP、IOC等通用的功能，对于这部分功能，咱们不该该把他们和真正的业务逻辑混淆在一块儿。对于应用类项目是这样，对于框架类项目也是这样，若是某一部分的代码量很是大，彻底有理由为它分出一个单独的包。对于RPC项目，咱们可能就会把客户端和服务端通信的消息放在common包内，把配置的处理单独放在config包内。
功能。也就是要实现一个框架主要解决的问题点，好比对于上面提到的RPC框架的core部分，能够想到的是咱们主要解决是客户端如何找到服务端，如何把进行方法调用以及把方法的调用信息传给目标服务端，服务端如何接受到这样的信息根据配置在本地实例化对象调用方法后把结果返回客户端三大问题，那么咱们可能会把项目分为routing、client、server等几个包。

若是是一个RPC框架，大概是这样的结构：

对于咱们的Web MVC框架，举例以下：

咱们能够有一个mvc.core项目，细分以下的包：
1. common：公共的一组件，下面的各模块都会用到
2. config：配置模块，解决框架的配置问题
3. startup：启动模块，解决框架和Servlet如何进行整合的问题
4. plugin：插件模块，插件机制的实现，提供IPlugin的抽象实现
5. routing：路由模块，解决请求路径的解析问题，提供了IRoute的抽象实现和基本实现
6. controller：控制器模块，解决的是如何产生控制器
7. model：视图模型模块，解决的是如何绑定方法的参数
8. action：action模块，解决的是如何调用方法以及方法返回的结果，提供了IActionResult的抽象实现和基本实现
9. view：视图模块，解决的是各类视图引擎和框架的适配
10. filter：过滤器模块，解决是执行Action，返回IActionResult先后的AOP功能，提供了IFilter的抽象实现以及基本实现
咱们能够再建立一个mvc.extension项目，细分以下的包：
1. filters：一些IFilter的实现
2. results：一些IActionResult的实现
3. routes：一些IRoute的实现
4. plugins：一些IPlugin的实现

这里咱们以IXXX来描述一个抽象，能够是接口也能够是抽象类，在具体实现的时候根据需求再来肯定。

这种结构的划分方式彻底吻合上面说的切蛋糕方式，能够看到除了横切部分和分层部分，做为一个Web MVC框架，它核心的组件就是routing、model、view、controller、action（固然，对于有些MVC框架它没有route部分，route部分是交由Web框架实现的）。

若是咱们在这个时候还没法肯定框架的模块划分的话，问题也不大，咱们能够在后续的搭建龙骨的步骤中随着更多的类的创建，继续理清和肯定模块的划分。

通过了设计的步骤，咱们应该内心对下面的问题有一个初步的规划了：

咱们的框架以什么形式来提供如何优雅的API？
咱们的框架包含哪些模块，模块大概的做用是什么？

搭建龙骨

在通过了初步的设计以后，咱们能够考虑为框架搭建一套龙骨，一套抽象的层次关系。也就是用抽象类、接口或空的类实现框架，能够经过编译，让框架撑起来，就像造房子搭建房子的钢筋混凝土结构（添砖加瓦是后面的事情，咱们先要有一个结构）。对于开发应用程序来讲，其实没有什么撑起来一说，由于应用程序中不少模块都是并行的，它可能并无一个主结构，主流程，而对于框架来说，它每每是一个高度面向对象的，高度抽象的一套程序，搭建龙骨也就是搭建一套抽象层。这么说可能有点抽象，咱们仍是来想一下若是要作一个Web MVC框架，须要怎么为上面说的几个核心模块进行抽象（咱们也来体会一下框架中一些类的命名，这里咱们为了更清晰，为全部接口都命名为IXXX，这点不太符合Java的命名规范）：

routing MVC的入口是路由
1. 每个路由都是IRoute表明了不一样的路由实现，它也提供一个getRouteResult()方法来返回RouteResult对象
2. 咱们实现一个框架自带的DefaultRoute，使得路由支持配置，支持默认值，支持正则表达式，支持约束等等
3. 咱们须要有一个Routes类来管理全部的路由IRoute，提供一个findRoute()方法来返回RouteResult对象，天然咱们这边调用的就是IRoute的getRouteResult()方法，返回能匹配到的结果
4. RouteResult对象就是匹配的路由信息，包含了路由解析后的全部数据
controller 路由下来是控制器
1. 咱们有IControllerFactory来建立Controller，提供createController()方法来返回IController
2. IController表明控制器，提供一个execute()方法来执行控制器
3. 咱们实现一个框架自带的DefaultControllerFactory来以约定因为配置的方式根据约定规则以及路由数据RouteResult来找到IController并建立它
4. 咱们为IController提供一个抽象实现，AbstractController，要求全部MVC框架的使用者建立的控制器须要继承AbstractController，在这个抽象实现中我们能够编写一些便捷的API以便开发人员使用，好比view()方法、file()方法、redirect()方法、json()方法、js()方法等等
action 找到了控制器后就是来找要执行的方法了
1. 咱们有IActionResult来表明Action返回的结果，提供一个execute()方法来执行这个结果
2. 咱们的框架须要实现一些自带的IActionResult，好比ContentResult、ViewResult、FileResult、JsonResult、RedirectResult来对应AbstractController的一些便捷方法
3. 再来定义一个IActionInvoker来执行Action，提供一个invokeAction()方法
4. 咱们须要实现一个DefaultActionInvoker以默认的方式进行方法的调用，也就是找到方法的一些IFilter按照必定的顺序执行他们，最后使用反射进行方法的调用获得上面说的IActionResult并执行它的execute()方法
filter 咱们的框架很重要的一点就是便捷的过滤器
1. 刚才提到了IFilter，表明的是一个过滤器，咱们提供IActionFilter对方法的执行先后进行过滤，提供IResultFilter对IActionResult执行先后进行过滤
2. 咱们的IActionInvoker怎么找到须要执行的IFilter呢，咱们须要定义一个IFilterProvider来提供过滤器，它提供一个getFilters()方法来提供全部的IFilter的实例
3. 咱们的框架能够实现一些自带的 IFilterProvider，好比AnnotationFilterProvider经过扫描Action或Controller上的注解来获取须要执行的过滤器信息；好比咱们还能够实现GlobalFilterProvider，开发人员能够直接经过配置或代码方式告知框架应用于全局的 IFilter
4. 既然咱们实现了多个IFilterProvider，咱们天然须要有一个类来管理这些IFilterProvider，咱们实现一个FilterProviders类并提供getFilters()方法（这和咱们的Routes类来管理IRoute是相似的，命名统一）
view 各类IActionResult中最特殊最复杂的就是ViewResult，咱们须要有一个单独的包来处理ViewResult的逻辑
1. 咱们须要有IViewEngine来表明一个模版引擎，提供一个getViewEngineResult()方法返回ViewEngineResult
2. ViewEngineResult包含视图引擎寻找视图的结果信息，里面包含IView和寻找的一些路径等
3. IView天然表明的是一个视图，提供render()方法（或者为了统一也能够叫作execute）来渲染视图
4. 咱们的框架能够实现常见的一些模版引擎，好比 FreemarkerViewEngine、VelocityViewEngine等，VelocityViewEngine返回的 ViewEngineResult天然包含的是一个实现IView的VelocityView，不会返回其它引擎的IView
5. 一样的，咱们是否是须要一个ViewEngines来管理全部的IViewEngine呢，一样也是实现findViewEngine()方法
common 这里能够放一些项目中各个模块都要用到的一些东西
1. 好比各类context，context表明的是执行某个任务须要的环境信息，这里咱们能够定义HttpContext、ControllerContext、ActionContext和ViewContext，后者继承前者，随着MVC处理流程的进行，View执行时的上下文相比Action执行时的上下文信息确定是多了视图的信息，其它同理，之因此把这个信息放在common里面而不是放在各个模块本身的包内是由于这样更清晰，能够一目了然各类对象的执行上下文有一个立体的概念
2. 好比各类helper或utility

接下去就再也不详细阐述model、plugin等模块的内容了。

看到这里，咱们来总结一下，咱们的MVC框架在组织结构上有着高度的统一：

若是xxx自己并没有选择策略，但xxx的建立过程也不是一个new这么简单的，能够由xxxFactory类来提供一个xxx
若是咱们须要用到不少个yyy，那么咱们会有各类yyyProvider（经过getyyy()方法）来提供这些yyy，而且咱们须要有一个yyyProviders来管理这些yyyProvider
若是zzz的选择是有策略性的，会按照须要选择zzz1或zzzN，那么咱们可能会有一个zzzs来管理这些zzz而且（经过findzzz()方法）来提供合适的zzz

同时咱们框架的相关类的命名也是很是统一的，能够一眼看出这是实现、仍是抽象类仍是接口；是提供程序，是执行结果仍是上下文。固然，在未来的代码实现过程当中极可能会把不少接口变为抽象类提供一些默认的实现，这并不会影响项目的主结构。咱们会在模式篇对框架经常使用的一些高层设计模式作更多的介绍。

到了这里，咱们的项目里已经有几十个空的（抽象）类、接口了，其中也定义了各类方法能够把各个模块串起来（各类find()方法和execute()方法），能够说整个项目的龙骨已经创建起来了，这种感受很好，由于我们内心颇有底，咱们只须要在接下去的工做中作两个事情：

实现各类DefaultXXX来走通主流程
实现各类IyyyProvider和Izzz接口来完善支线流程

走通主线流程

所谓走通主线流程，就是让这个框架能够以一个HelloWorld形式跑起来，这就须要把几个核心类的核心方法使用最简单的方式进行实现，仍是拿咱们的MVC框架来举例子：

从startup开始，可能须要实现ServletContextListener来动态注册咱们框架的入口Servlet，暂且起名为DispatcherServlet吧，在这个类中咱们须要走一下主线流程
1. 调用Routes.findRoute()得到IRoute
2. 调用IRoute.getRouteResult()来得到RouteResult
3. 使用拿到的RouteResult做为参数调用DefaultControllerFactory.createController()得到IController（其实也是AbstractController）
4. 调用IController.execute()
在config中建立一个IConfig做为一种配置方式，我们实现一个DefaultConfig，把各类默认实现注册到框架中去，也就是DefaultRoute、 DefaultControllerFactory、DefaultActionInvoker，而后把各类IViewEngine加入 ViewEngines
而后须要完成相关默认类的实现：
1. 实现Routes.findRoute()
2. 实现DefaultRoute.getRouteResult()
3. 实现DefaultControllerFactory.createController()
4. 实现AbstractController.execute()
5. 实现DefaultActionInvoker.invokeAction()
6. 实现ViewResult.execute()
7. 实现ViewEngines.findViewEngine()
8. 实现VelocityViewEngine.getViewEngineResult()
9. 实现VelocityView.render()

在这一步，咱们并不必定要去触碰filter和model这部分的内容，咱们的主线流程只是解析路由，得到控制器，执行方法，找到视图而后渲染视图。过滤器和视图模型的绑定属于加强型的功能，属于支线流程，不属于主线流程。

虽然在这里咱们说了一些MVC的实现，但本文的目的不在于教你实现一个MVC框架，因此不用深究每个类的实现细节，这里想说的是，在前面的龙骨搭建完后，你会发现按照这个龙骨为它加一点肉上去实现主要的流程是顺理成章的事情，毫无痛苦。在整个实现的过程当中，你能够不断完善common下的一些context，把方法的调用参数封装到上下文对象中去，不但看起来清楚且符合开闭原则。到这里，咱们应该能够跑起来在设计阶段作的那个示例网站的HelloWorld功能了。

在这里还想说一点，有些人在实现框架的时候并无搭建龙骨的一步骤，直接以非OOP的方式实现了主线流程，这种方式有如下几个缺点：

不容易作到SRP单一指责原则，你很容易把各类逻辑都集中写在一块儿，好比大量的逻辑直接写到了DispatcherServlet中，辅助一些Service或Helper，整个框架就肥瘦不匀，有些类特别庞大有些类特别小。
不容易作到OCP开闭原则，扩展起来不方便须要修改老的代码，咱们指望的扩展是实现新的类而后让框架感知，而不是直接修改框架的某些代码来加强功能。
很难实现DIP依赖倒置原则，即便你依赖的确实是IService但其实就没意义，由于它只有一个实现，只是把他看成帮助类来用罢了。

实现各类支线流程

咱们想一下，对于这个MVC框架有哪些没有实现的支线流程？其实无需多思考，由于咱们在搭建龙骨阶段的设计已经给了咱们明确的方向了，咱们只须要把除了主线以外的那些龙骨上也填充一些实体便可，好比：

实现更多的IRoute，并注册到Routes
实现更多的IViewEngine，并注册到ViewEngines
实现必要的IFilterProvider以及FilterProviders，把IFilterProvider注册到FilterProviders
加强DefaultActionInvoker.invokeAction()方法，在合适的时候调用这些IFilter
实现更多的IActionResult，而且为AbstractController实现更多的便捷方法来返回这些IActionResult
……实现更多model模块的内容和plugin模块的内容

实现了这一步后，你会发现整个框架饱满起来了，每个包中再也不是仅有的那些接口和默认实现，并且会有一种OOP的爽快感，爽快感来源于几个方面：

面对接口编程抽象和多态的放心安心的爽快感
为抽象类实现具体类享受到父类大量实现的知足的爽快感
实现了大量的接口和抽象类后充实的爽快感

咱们再来总结一下以前说的那些内容，实现一个框架的第一大步就是：

设计一套合理的接口
为框架进行模块划分
为框架搭建由抽象结构构成的骨架
在这个骨架的基础上实现一个HelloWorld程序
为这个骨架的其它部分填充更多实现

通过这样的一些步骤后能够发现这个框架是很稳固的，很平衡的，很易于扩展的。其实到这里不少人以为框架已经完成了，有血有肉，其实我的以为只能说开发工做实现了差很少30%，后文会继续说，毕竟直接把这样一个血肉之躯拿出去对外有点吓人，咱们须要为它进行不少包装和完善。

做者： lovecindywang

转自：http://www.cnblogs.com/lovecindywang/p/4447739.html

本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文链接，不然保留追究法律责任的权利。