如何写一个框架Word文档下载推荐.docx

如何写一个框架Word文档下载推荐.docx

《如何写一个框架Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《如何写一个框架Word文档下载推荐.docx（22页珍藏版）》请在冰豆网上搜索。

除非是练手项目，一般我们是有了解决不了问题的时候才会考虑不使用既有的成熟的框架而重复造轮子的，这个时候需要列出新框架主要希望解决什么问题。

有关是否应该重复造轮子的话题讨论了很多，我的建议是在把问题列清后进行简单的研究看看是否可以通过扩展现有的框架来解决这个问题。

一般而言大部分成熟的框架都有一定的扩展和内部组件的替换能力，可以解决大部分技术问题，但在如下情况下我们可能不得不自己去写一个框架，比如即使通过扩展也无法满足技术需求、安全原因、需要更高的生产力、需要让框架和公司内部的流程更好地进行适配、开源的普适框架无法满足性能需求、二次开发的成本高于重新开发的成本等等。

主打轻量级？

轻量级是很多人打算自己写一个新框架的原因，但我们要明白，大部分项目在一开始的时候其实都是轻量级的，随着框架的用户越来越多，它必定需要满足各种奇怪的需求，在经过了无数次迭代之后，框架的主线流程就会多很多扩展点、检测点，这样框架势必变得越来越重（从框架的入口到框架的工作结束的方法调用层次越来越多，势必框架也就越来越慢），如果你打算把框架定位于一个轻量级的框架的话，那么在今后的迭代过程中需要进行一些权衡，在心中有坚定的轻量级的理念的同时不断做性能测试来确保框架的轻量，否则随着时间的发展框架可能会越来越重进而偏离了开始的定位。

特性？

如果你打算写一个框架，并且只有轻量级这一个理由的话，你或许应该再为自己的框架想一些新特性，就像做一个产品一样，如果找不出两个以上的亮点，那么这个产品不太可能成功，比如你的新框架可以是一个零配置的框架，可以是一个前端开发也能用的后端框架。

其它？

一般来说框架是给程序员使用的，我们要考虑框架使用的频度是怎么样的，这可能决定的框架的性能需求和稳定性需求。

还有，需要考虑框架将来怎么发展，是希望走开源路线还是商业路线。

当然，这些问题也可以留到框架有一个大致的结构后再去考虑。

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

调研

虽然到这里你已经决定去写一个框架了，但是在着手写之前还是至少建议评估一下市面上的类似（成熟）框架。

需要做的是通读这些框架的文档以及阅读一些源码，这么做有几个目的：

通过分析现有框架的功能，可以制定出一个新框架要实现的功能列表。

通过分析现有框架的问题，总结出新框架需要避免的东西和改善的地方。

通过阅读现有框架的源码，帮助自己理清框架的主线流程为总体设计做铺垫（后面总体设计部分会更多谈到）。

如果能充分理解现有的框架，那么你就是站在巨人的肩膀上写框架，否则很可能就是在井底造轮子。

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

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

起手零配置，总体上约定由于配置，即使需要扩展配置也支持通过代码和配置文件两种方式进行配置。

除了Servlet之外不依赖其它类库，支持通过插件方式和诸如Spring等框架进行整合。

更优化的项目结构，不需要按照传统的JavaWeb项目结构那样来分离代码和WEB-INF，视图可以和代码在一起，阅读代码更便利。

拦截器和框架本身更紧密，提供Action、Controller和Global三个级别的"

拦截器"

（或者说过滤器）。

丰富的Action的返回值，返回的可以是视图、可以是重定向、可以是文件、可以是字符串、可以是Json数据，可以是Javascript代码等等。

支持针对测试环境自动生成测试的视图模型数据，以便前端和后端可以同时开发项目。

支持在开发的时候自动生成路由信息、模型绑定、异常处理等配置的信息页面和调试页面，方便开发和调试。

提供一套通用的控件模版，使得，并且支持多种模版引擎，比如Jsp、Velocity、Freemarker、Mustache等等。

嗯，看上去挺诱人的，这是一个不错的开端，如果你要写的框架自己都不觉得想用的话，那么别人就更不会有兴趣来尝试使用你的框架了。

解决难点

之所以把解决难点放在开搞之前是因为，如果实现这个框架的某些特性，甚至说实现这个框架的主流程有一些核心问题难以解决，那么就要考虑对框架的特性进行调整，甚至取消框架的开发计划了。

有的时候我们在用A平台的时候发现一个很好用的框架，希望把这个框架移植到B平台，这个想法是好的，但之所以在这以前这么多年没有人这么干过是因为这个平台的限制压根不可能实现这样的东西。

比如我们要实现一个MVC框架，势必需要依赖平台提供的反射特性，如果你的语言平台压根就没有运行时反射这个功能，那么这就是一个非常难以解决的难点。

又比如我们在某个平台实现一个类似于.NET平台Linq2Sql的数据访问框架，但如果这个目标平台的开发语言并不像C#那样提供了类型推断、匿名类型、Lambda表达式、扩展方法的话那么由于语法的限制你写出来的框架在使用的时候是无法像.NET平台Linq2Sql那样优雅的，这就违背了实现框架的主要目的，实现新的框架也就变得意义不大了。

对于我们要实现的MVC框架貌似不存在什么根本性的无法解决的问题，毕竟在Java平台已经有很多可以参考的例子了。

如果框架的实现总体上没什么问题的话，就需要逐一评估框架的这些新特性是否可以解决。

建议对于每一个难点特性做一个原型项目来证明可行，以免在框架实现到一半的时候发现有无法解决的问题就比较尴尬了。

分析一下，貌似我们要实现的这8大特性只有第1点要研究一下，看看如何免配置通过让代码方式让我们的WebMVC框架可以和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都有一套统一的规范，比如入口都叫XXX