所謂定位就是回答幾個(gè)問題，我出于什么目的要寫一個(gè)框架，我的這個(gè)框架是干什么的，有什么特性適用于什么場(chǎng)景，我的這個(gè)框架的用戶對(duì)象是誰，他們會(huì)怎么使用，框架由誰維護(hù)將來怎么發(fā)展等等。

1. 如果你打算寫框架，那么肯定心里已經(jīng)有一個(gè)初步的定位，比如它是一個(gè)緩存框架、Web MVC框架、IOC框架、ORM/數(shù)據(jù)訪問框架、RPC框架或是一個(gè)用于Web開發(fā)的全棧式框架。
2. 是 否要重復(fù)造輪子？除非是練手項(xiàng)目，一般我們是有了解決不了問題的時(shí)候才會(huì)考慮不使用既有的成熟的框架而重復(fù)造輪子的，這個(gè)時(shí)候需要列出新框架主要希望解決 什么問題。有關(guān)是否應(yīng)該重復(fù)造輪子的話題討論了很多，我的建議是在把問題列清后進(jìn)行簡(jiǎn)單的研究看看是否可以通過擴(kuò)展現(xiàn)有的框架來解決這個(gè)問題。一般而言大 部分成熟的框架都有一定的擴(kuò)展和內(nèi)部組件的替換能力，可以解決大部分技術(shù)問題，但在如下情況下我們可能不得不自己去寫一個(gè)框架，比如即使通過擴(kuò)展也無法滿 足技術(shù)需求、安全原因、需要更高的生產(chǎn)力、需要讓框架和公司內(nèi)部的流程更好地進(jìn)行適配、開源的普適框架無法滿足性能需求、二次開發(fā)的成本高于重新開發(fā)的成 本等等。
3. 主打輕量級(jí)？輕量級(jí)是很多人打算自己寫一個(gè)新框架的原因，但我們要明白，大部分項(xiàng)目在一開始的時(shí)候其實(shí)都是輕量級(jí)的，隨著框架 的用戶越來越多，它必定需要滿足各種奇怪的需求，在經(jīng)過了無數(shù)次迭代之后，框架的主線流程就會(huì)多很多擴(kuò)展點(diǎn)、檢測(cè)點(diǎn)，這樣框架勢(shì)必變得越來越重（從框架的 入口到框架的工作結(jié)束的方法調(diào)用層次越來越多，勢(shì)必框架也就越來越慢），如果你打算把框架定位于一個(gè)輕量級(jí)的框架的話，那么在今后的迭代過程中需要進(jìn)行一 些權(quán)衡，在心中有堅(jiān)定的輕量級(jí)的理念的同時(shí)不斷做性能測(cè)試來確保框架的輕量，否則隨著時(shí)間的發(fā)展框架可能會(huì)越來越重進(jìn)而偏離了開始的定位。
4. 特性？如果你打算寫一個(gè)框架，并且只有輕量級(jí)這一個(gè)理由的話，你或許應(yīng)該再為自己的框架想一些新特性，就像做一個(gè)產(chǎn)品一樣，如果找不出兩個(gè)以上的亮點(diǎn)，那么這個(gè)產(chǎn)品不太可能成功，比如你的新框架可以是一個(gè)零配置的框架，可以是一個(gè)前端開發(fā)也能用的后端框架。
5. 其它？一般來說框架是給程序員使用的，我們要考慮框架使用的頻度是怎么樣的，這可能決定的框架的性能需求和穩(wěn)定性需求。還有，需要考慮框架將來怎么發(fā)展，是希望走開源路線還是商業(yè)路線。當(dāng)然，這些問題也可以留到框架有一個(gè)大致的結(jié)構(gòu)后再去考慮。

我們來為本文模擬一個(gè)場(chǎng)景，假設(shè)我們覺得現(xiàn)有的Spring MVC等框架開發(fā)起來效率有點(diǎn)低，打算重復(fù)造輪子，對(duì)于新框架的定位是一個(gè)給Java程序員使用的輕量級(jí)的、零配置的、易用的、易擴(kuò)展的Web MVC框架。

調(diào)研

雖然到這里你已經(jīng)決定去寫一個(gè)框架了，但是在著手寫之前還是至少建議評(píng)估一下市面上的類似（成熟）框架。需要做的是通讀這些框架的文檔以及閱讀一些源碼，這么做有幾個(gè)目的：

1. 通過分析現(xiàn)有框架的功能，可以制定出一個(gè)新框架要實(shí)現(xiàn)的功能列表。
2. 通過分析現(xiàn)有框架的問題，總結(jié)出新框架需要避免的東西和改善的地方。
3. 通過閱讀現(xiàn)有框架的源碼，幫助自己理清框架的主線流程為總體設(shè)計(jì)做鋪墊（后面總體設(shè)計(jì)部分會(huì)更多談到）。
4. 如果能充分理解現(xiàn)有的框架，那么你就是站在巨人的肩膀上寫框架，否則很可能就是在井底造輪子。

新 開發(fā)一個(gè)框架的好處是沒有兼容歷史版本的包袱，但是責(zé)任也同樣重大，因?yàn)槿绻麑?duì)于一開始的定位或設(shè)計(jì)工作沒有做好的話，將來如果要對(duì)格局進(jìn)行改變就會(huì)有巨 大的向前兼容的包袱（除非你的框架沒有在任何正式項(xiàng)目中使用），兼容意味著框架可能會(huì)越來越重，可能會(huì)越來越難看，閱讀至少一到兩個(gè)開源實(shí)現(xiàn)，做好充分的 調(diào)研工作可以使你避免犯大錯(cuò)。

假設(shè)我們?cè)u(píng)估了一些主流框架后已經(jīng)很明確，我們的MVC框架是一個(gè)Java平臺(tái)的、基于Servlet的輕量級(jí)的Web MVC框架，主要的理念是約定優(yōu)于配置，高內(nèi)聚大于低耦合，提供主流Web MVC框架的大部分功能，并且易用方面有所創(chuàng)新，新特性體包括：

1. 起手零配置，總體上約定由于配置，即使需要擴(kuò)展配置也支持通過代碼和配置文件兩種方式進(jìn)行配置。
2. 除了Servlet之外不依賴其它類庫，支持通過插件方式和諸如Spring等框架進(jìn)行整合。
3. 更優(yōu)化的項(xiàng)目結(jié)構(gòu)，不需要按照傳統(tǒng)的Java Web項(xiàng)目結(jié)構(gòu)那樣來分離代碼和WEB-INF，視圖可以和代碼在一起，閱讀代碼更便利。
4. 攔截器和框架本身更緊密，提供Action、Controller和Global三個(gè)級(jí)別的"攔截器"（或者說過濾器）。
5. 豐富的Action的返回值，返回的可以是視圖、可以是重定向、可以是文件、可以是字符串、可以是Json數(shù)據(jù)，可以是Javascript代碼等等。
6. 支持針對(duì)測(cè)試環(huán)境自動(dòng)生成測(cè)試的視圖模型數(shù)據(jù)，以便前端和后端可以同時(shí)開發(fā)項(xiàng)目。
7. 支持在開發(fā)的時(shí)候自動(dòng)生成路由信息、模型綁定、異常處理等配置的信息頁面和調(diào)試頁面，方便開發(fā)和調(diào)試。

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

嗯，看上去挺誘人的，這是一個(gè)不錯(cuò)的開端，如果你要寫的框架自己都不覺得想用的話，那么別人就更不會(huì)有興趣來嘗試使用你的框架了。

#p#
解決難點(diǎn)

之 所以把解決難點(diǎn)放在開搞之前是因?yàn)?，如果?shí)現(xiàn)這個(gè)框架的某些特性，甚至說實(shí)現(xiàn)這個(gè)框架的主流程有一些核心問題難以解決，那么就要考慮對(duì)框架的特性進(jìn)行調(diào) 整，甚至取消框架的開發(fā)計(jì)劃了。有的時(shí)候我們?cè)谟肁平臺(tái)的時(shí)候發(fā)現(xiàn)一個(gè)很好用的框架，希望把這個(gè)框架移植到B平臺(tái)，這個(gè)想法是好的，但之所以在這以前這么 多年沒有人這么干過是因?yàn)檫@個(gè)平臺(tái)的限制壓根不可能實(shí)現(xiàn)這樣的東西。比如我們要實(shí)現(xiàn)一個(gè)MVC框架，勢(shì)必需要依賴平臺(tái)提供的反射特性，如果你的語言平臺(tái)壓 根就沒有運(yùn)行時(shí)反射這個(gè)功能，那么這就是一個(gè)非常難以解決的難點(diǎn)。又比如我們?cè)谀硞€(gè)平臺(tái)實(shí)現(xiàn)一個(gè)類似于.NET平臺(tái)Linq2Sql的數(shù)據(jù)訪問框架，但如 果這個(gè)目標(biāo)平臺(tái)的開發(fā)語言并不像C#那樣提供了類型推斷、匿名類型、Lambda表達(dá)式、擴(kuò)展方法的話那么由于語法的限制你寫出來的框架在使用的時(shí)候是無 法像.NET平臺(tái)Linq2Sql那樣優(yōu)雅的，這就違背了實(shí)現(xiàn)框架的主要目的，實(shí)現(xiàn)新的框架也就變得意義不大了。

對(duì)于我們要實(shí)現(xiàn)的MVC框 架貌似不存在什么根本性的無法解決的問題，畢竟在Java平臺(tái)已經(jīng)有很多可以參考的例子了。如果框架的實(shí)現(xiàn)總體上沒什么問題的話，就需要逐一評(píng)估框架的這 些新特性是否可以解決。建議對(duì)于每一個(gè)難點(diǎn)特性做一個(gè)原型項(xiàng)目來證明可行，以免在框架實(shí)現(xiàn)到一半的時(shí)候發(fā)現(xiàn)有無法解決的問題就比較尷尬了。

分析一下，貌似我們要實(shí)現(xiàn)的這8大特性只有第1點(diǎn)要研究一下，看看如何免配置通過讓代碼方式讓我們的Web MVC框架可以和Servlet進(jìn)行整合，如果無法實(shí)現(xiàn)的話，我們可能就需要把第1點(diǎn)特性從零配置改為一分鐘快速配置了。

開搞

首先需要給自己框架取一個(gè)名字，取名要考慮到易讀、易寫、易記，也需要盡量避免和市面上其它產(chǎn)品的名字重復(fù)，還有就是最好不要起一個(gè)侮辱其它同類框架的名字以免引起公憤。
如果將來打算把項(xiàng)目搞大的話，可以提前注冊(cè)一下項(xiàng)目的相關(guān)域名，畢竟現(xiàn)在域名也便宜，避免到時(shí)候項(xiàng)目名和域名差距很大，或項(xiàng)目的.com或.org域名對(duì)應(yīng)了一個(gè)什么不太和諧的網(wǎng)站這就尷尬了。
然后就是找一個(gè)地方來托管自己的代碼，如果一開始不希望公開代碼的話，最好除了本地源代碼倉庫還有一個(gè)異地的倉庫以免磁盤損壞導(dǎo)致抱憾終身，當(dāng)然如果不怕出丑的話也可以在起步的時(shí)候就使用Github等網(wǎng)站來托管自己的代碼。

#p#
總體設(shè)計(jì)

對(duì) 于總體設(shè)計(jì)我的建議是一開始不一定需要寫什么設(shè)計(jì)文檔畫什么類圖，因?yàn)榭赡芤婚_始的時(shí)候無法形成這么具體的概念，我們可以直接從代碼開始做第一步?？蚣艿?使用者一般而言還是開發(fā)人員，拋開框架的內(nèi)在的實(shí)現(xiàn)不說，框架的API設(shè)計(jì)的好壞取決于兩個(gè)方面。對(duì)于普通開發(fā)人員而言就是使用層面的API是否易于使 用，拿我們的MVC框架舉例來說：

最基本的，搭建一個(gè)HelloWorld項(xiàng)目，聲明一個(gè)Controller和Action，配置一個(gè)路由規(guī)則讓Get方法的請(qǐng)求可以解析到這個(gè)Action，可以輸出HelloWorld文字，怎么實(shí)現(xiàn)？
如果要實(shí)現(xiàn)從Cookie以及表單中獲取相關(guān)數(shù)據(jù)綁定到Action的參數(shù)里面，怎么實(shí)現(xiàn)？
如果要配置一個(gè)Action在調(diào)用前需要判斷權(quán)限，在調(diào)用后需要記錄日志，怎么實(shí)現(xiàn)？

我們這里說的API，它不一定全都是方法調(diào)用的API，廣義上來說我們認(rèn)為框架提供的接入層的使用都可以認(rèn)為是API，所以上面的一些功能都可以認(rèn)為是MVC框架的API。

框架除了提供基本的功能，還要提供一定程度的擴(kuò)展功能，使得一些復(fù)雜的項(xiàng)目能夠在某些方面對(duì)框架進(jìn)行增強(qiáng)以適應(yīng)各種需求，比如：

1. 我的Action是否可以返回圖片驗(yàn)證碼？
2. 我的Action的參數(shù)綁定是否可以從Memcached中獲取數(shù)據(jù)？
3. 如果出現(xiàn)異常，能否在開發(fā)的時(shí)候顯示具體的錯(cuò)誤信息，在正式環(huán)境顯示友好的錯(cuò)誤頁面并且記錄錯(cuò)誤信息到數(shù)據(jù)庫？

一 般而言如果要實(shí)現(xiàn)這樣的功能就需要自己實(shí)現(xiàn)框架公開的一些類或接口，然后把自己的實(shí)現(xiàn)"注冊(cè)"到框架中，讓框架可以在某個(gè)時(shí)候去使用這些新的實(shí)現(xiàn)。這就需 要框架的設(shè)計(jì)者來考慮應(yīng)該以怎么樣的友好形式公開出去哪些內(nèi)容，使得以后的擴(kuò)展實(shí)現(xiàn)在自由度以及最少實(shí)現(xiàn)上的平衡，同時(shí)要兼顧外來的實(shí)現(xiàn)不破壞框架已有的 結(jié)構(gòu)。

要想清楚這些不是一件容易的事情，所以在框架的設(shè)計(jì)階段完全可以使用從上到下的方式進(jìn)行設(shè)計(jì)。也就是不去考慮框架怎么實(shí)現(xiàn)，而是以一 個(gè)使用者的身份來寫一個(gè)框架的示例網(wǎng)站，API怎么簡(jiǎn)單怎么舒服就怎么設(shè)計(jì)，只從使用者的角度來考慮問題。對(duì)于相關(guān)用到的類，直接寫一個(gè)空的類（能用接口 的盡量用接口，你的目的只是通過編譯而不是能運(yùn)行起來），讓程序可以通過編譯就可以了。你可以從框架的普通使用開始寫這樣一個(gè)示例網(wǎng)站，然后再寫各種擴(kuò)展 應(yīng)用，在此期間你可能會(huì)用到框架內(nèi)部的20個(gè)類，這些類就是框架的接入類，在你的示例網(wǎng)站通過編譯的那剎那，其實(shí)你已經(jīng)實(shí)現(xiàn)了框架的接入層的設(shè)計(jì)。

這里值得一說的是API的設(shè)計(jì)蘊(yùn)含了非常多的學(xué)問以及經(jīng)驗(yàn)，要在目標(biāo)平臺(tái)設(shè)計(jì)一套合理易用的API首先需要對(duì)目標(biāo)平臺(tái)足夠了解，每一個(gè)平臺(tái)都有一些約定俗成的規(guī)范，如果設(shè)計(jì)的API能符合這些規(guī)范那么開發(fā)人員會(huì)更容易接受這個(gè)框架，此外還有一些建議：

1. 之 所以我們把API的設(shè)計(jì)先行，而不是讓框架的設(shè)計(jì)先行是因?yàn)檫@樣我們更容易設(shè)計(jì)出好用的API，作為框架的實(shí)現(xiàn)者，我們往往會(huì)進(jìn)行一些妥協(xié)，我們可能會(huì)為 了在框架內(nèi)部DRY而設(shè)計(jì)出一套丑陋的API讓框架的使用者去做一些重復(fù)的工作；我們也可能會(huì)因?yàn)橄胱尶蚣茏兊酶神詈蠌?qiáng)迫框架的使用者去使用到框架的一 些內(nèi)部API去初始化框架的組件。如果框架不是易用的，那么框架的內(nèi)部設(shè)計(jì)的再合理又有什么意義？
2. 盡量少暴露一些框架內(nèi)部的類名吧，對(duì) 于框架的使用者來說，你的框架對(duì)他一點(diǎn)都不熟悉，如果要上手你的框架需要學(xué)習(xí)一到兩個(gè)類尚可接受，如果要使用到十幾個(gè)類會(huì)頭暈?zāi)X脹的，即使你的框架有非常 多的功能以及配置，可以考慮提供一個(gè)入口類，比如創(chuàng)建一個(gè)ConfigCenter類作為入口，讓使用者可以僅僅探索這個(gè)類便可對(duì)框架進(jìn)行所有的配置。
3. 一 個(gè)好的框架是可以讓使用者少犯錯(cuò)誤的，框架的設(shè)計(jì)者務(wù)必要考慮到，框架的使用者沒有這個(gè)業(yè)務(wù)來按照框架的最佳實(shí)踐來做，所以在設(shè)計(jì)API的時(shí)候，如果你希 望API的使用者一定要按照某個(gè)方式來做的話，可以考慮設(shè)置一個(gè)簡(jiǎn)便的重載來加載默認(rèn)的最合理的使用方式而不是要求使用者來為你的方法初始一些什么依賴， 同時(shí)也可以在API內(nèi)部做一些檢測(cè)，如果發(fā)現(xiàn)開發(fā)人員可能會(huì)犯錯(cuò)進(jìn)行一些提示或拋出異常。好的框架無需過多的文檔，它可以在開發(fā)人員用的時(shí)候告知它哪里錯(cuò) 了，最佳實(shí)踐是什么，即便他們真的錯(cuò)了也能以默認(rèn)的更合理的方式來彌補(bǔ)這個(gè)錯(cuò)誤。
4. 建議所有的API都有一套統(tǒng)一的規(guī)范，比如入口都叫XXXCenter或XXXManager，而不是叫XXXCenter、YYYManager和 ZZZService。API往往需要進(jìn)行迭代和改良的，在首個(gè)版本中把好名字用掉也不一定是一個(gè)好辦法，最好還是給自己的框架各種API的名字留一點(diǎn)余 地，這樣以后萬一需要升級(jí)換代不至于太牽強(qiáng)。

下一步工作就是把項(xiàng)目中那些空的類按照功能進(jìn)行劃分。目的很簡(jiǎn)單，就是讓你的框架 的100個(gè)類或接口能夠按照功能進(jìn)行拆分和歸類，這樣別人一打開你的框架就可以馬上知道你的框架分為哪幾個(gè)主要部分，而不是在100個(gè)類中暈眩；還有因?yàn)?一旦在你的框架有使用者后你再要為API相關(guān)的那些類調(diào)整包就比困難了，即使你在創(chuàng)建框架的時(shí)候覺得我的框架就那么十幾個(gè)類無需進(jìn)行過多的分類，但是在將 來框架變大又發(fā)現(xiàn)當(dāng)初設(shè)計(jì)的不合理，無法進(jìn)行結(jié)構(gòu)調(diào)整就會(huì)變得很痛苦。因此這個(gè)工作還是相當(dāng)重要的，對(duì)于大多數(shù)框架來說，可以有幾種切蛋糕的方式：

1. 分 層。我覺得框架和應(yīng)用程序一樣，也需要進(jìn)行分層。傳統(tǒng)的應(yīng)用程序我們分為表現(xiàn)層、邏輯層和數(shù)據(jù)訪問層，類似的對(duì)于很多框架也可以進(jìn)行橫向的層次劃分。要分 層的原因是我們的框架要處理的問題是基于多層抽象的，就像如果沒有OSI七層模型，要讓一個(gè)HTTP應(yīng)用去直接處理網(wǎng)絡(luò)信號(hào)是不合理的也是不利于重用的。 舉一個(gè)例子，如果我們要寫一個(gè)基于Socket的RPC的框架，我們需要處理方法的代理以及序列化，以及序列化數(shù)據(jù)的傳輸，這完全是兩個(gè)層面的問題，前者 偏向于應(yīng)用層，后者偏向于網(wǎng)絡(luò)層，我們完全有理由把我們的框架分為兩個(gè)層面的項(xiàng)目（至少是兩個(gè)包），rpc.core和rpc.socket，前者不關(guān)心 網(wǎng)絡(luò)實(shí)現(xiàn)來處理所有RPC的功能，后者不關(guān)心RPC來處理所有的Socket功能，在將來即使我們要淘汰我們的RPC的協(xié)議了，我們也可以重用 rpc.socket項(xiàng)目，因?yàn)樗蚏PC的實(shí)現(xiàn)沒有任何關(guān)系，它關(guān)注的只是socket層面的東西。
2. 橫切。剛才說的分層是橫向的分 割，橫切是縱向的分割（橫切是跨多個(gè)模塊的意思，不是橫向來切的意思）。其實(shí)橫切關(guān)注點(diǎn)就是諸如日志、配置、緩存、AOP、IOC等通用的功能，對(duì)于這部 分功能，我們不應(yīng)該把他們和真正的業(yè)務(wù)邏輯混淆在一起。對(duì)于應(yīng)用類項(xiàng)目是這樣，對(duì)于框架類項(xiàng)目也是這樣，如果某一部分的代碼量非常大，完全有理由為它分出 一個(gè)單獨(dú)的包。對(duì)于RPC項(xiàng)目，我們可能就會(huì)把客戶端和服務(wù)端通訊的消息放在common包內(nèi)，把配置的處理單獨(dú)放在config包內(nèi)。
3. 功能。也就是要實(shí)現(xiàn)一個(gè)框架主要解決的問題點(diǎn)，比如對(duì)于上面提到的RPC框架的core部分，可以想到的是我們主要解決是客戶端如何找到服務(wù)端，如何把進(jìn) 行方法調(diào)用以及把方法的調(diào)用信息傳給目標(biāo)服務(wù)端，服務(wù)端如何接受到這樣的信息根據(jù)配置在本地實(shí)例化對(duì)象調(diào)用方法后把結(jié)果返回客戶端三大問題，那么我們可能 會(huì)把項(xiàng)目分為routing、client、server等幾個(gè)包。

如果是一個(gè)RPC框架，大概是這樣的結(jié)構(gòu)：

對(duì)于我們的Web MVC框架，舉例如下：

1. 我們可以有一個(gè)mvc.core項(xiàng)目，細(xì)分如下的包：
2. common：公共的一組件，下面的各模塊都會(huì)用到
3. config：配置模塊，解決框架的配置問題
4. startup：?jiǎn)?dòng)模塊，解決框架和Servlet如何進(jìn)行整合的問題
5. plugin：插件模塊，插件機(jī)制的實(shí)現(xiàn)，提供IPlugin的抽象實(shí)現(xiàn)
6. routing：路由模塊，解決請(qǐng)求路徑的解析問題，提供了IRoute的抽象實(shí)現(xiàn)和基本實(shí)現(xiàn)
7. controller：控制器模塊，解決的是如何產(chǎn)生控制器
8. model：視圖模型模塊，解決的是如何綁定方法的參數(shù)
9. action：action模塊，解決的是如何調(diào)用方法以及方法返回的結(jié)果，提供了IActionResult的抽象實(shí)現(xiàn)和基本實(shí)現(xiàn)
10. view：視圖模塊，解決的是各種視圖引擎和框架的適配
11. filter：過濾器模塊，解決是執(zhí)行Action，返回IActionResult前后的AOP功能，提供了IFilter的抽象實(shí)現(xiàn)以及基本實(shí)現(xiàn)
12. 我們可以再創(chuàng)建一個(gè)mvc.extension項(xiàng)目，細(xì)分如下的包：
13. filters：一些IFilter的實(shí)現(xiàn)
14. results：一些IActionResult的實(shí)現(xiàn)
15. routes：一些IRoute的實(shí)現(xiàn)
16. plugins：一些IPlugin的實(shí)現(xiàn)

這里我們以IXXX來描述一個(gè)抽象，可以是接口也可以是抽象類，在具體實(shí)現(xiàn)的時(shí)候根據(jù)需求再來確定。

這 種結(jié)構(gòu)的劃分方式完全吻合上面說的切蛋糕方式，可以看到除了橫切部分和分層部分，作為一個(gè)Web MVC框架，它核心的組件就是routing、model、view、controller、action（當(dāng)然，對(duì)于有些MVC框架它沒有route部 分，route部分是交由Web框架實(shí)現(xiàn)的）。

如果我們?cè)谶@個(gè)時(shí)候還無法確定框架的模塊劃分的話，問題也不大，我們可以在后續(xù)的搭建龍骨的步驟中隨著更多的類的建立，繼續(xù)理清和確定模塊的劃分。

經(jīng)過了設(shè)計(jì)的步驟，我們應(yīng)該心里對(duì)下面的問題有一個(gè)初步的規(guī)劃了：

• 我們的框架以什么形式來提供如何優(yōu)雅的API？
• 我們的框架包含哪些模塊，模塊大概的作用是什么？

#p#
搭建龍骨 

在 經(jīng)過了初步的設(shè)計(jì)之后，我們可以考慮為框架搭建一套龍骨，一套抽象的層次關(guān)系。也就是用抽象類、接口或空的類實(shí)現(xiàn)框架，可以通過編譯，讓框架撐起來，就像 造房子搭建房子的鋼筋混凝土結(jié)構(gòu)（添磚加瓦是后面的事情，我們先要有一個(gè)結(jié)構(gòu)）。對(duì)于開發(fā)應(yīng)用程序來說，其實(shí)沒有什么撐起來一說，因?yàn)閼?yīng)用程序中很多模塊 都是并行的，它可能并沒有一個(gè)主結(jié)構(gòu)，主流程，而對(duì)于框架來說，它往往是一個(gè)高度面向?qū)ο蟮?，高度抽象的一套程序，搭建龍骨也就是搭建一套抽象層。這么說 可能有點(diǎn)抽象，我們還是來想一下如果要做一個(gè)Web MVC框架，需要怎么為上面說的幾個(gè)核心模塊進(jìn)行抽象（我們也來體會(huì)一下框架中一些類的命名，這里我們?yōu)榱烁逦?，為所有接口都命名為IXXX，這點(diǎn)不太 符合Java的命名規(guī)范）：

1. routing MVC的入口是路由
2. 每一個(gè)路由都是IRoute代表了不同的路由實(shí)現(xiàn)，它也提供一個(gè)getRouteResult()方法來返回RouteResult對(duì)象
3. 我們實(shí)現(xiàn)一個(gè)框架自帶的DefaultRoute，使得路由支持配置，支持默認(rèn)值，支持正則表達(dá)式，支持約束等等
4. 我們需要有一個(gè)Routes類來管理所有的路由IRoute，提供一個(gè)findRoute()方法來返回RouteResult對(duì)象，自然我們這邊調(diào)用的就是IRoute的getRouteResult()方法，返回能匹配到的結(jié)果
5. RouteResult對(duì)象就是匹配的路由信息，包含了路由解析后的所有數(shù)據(jù)
6. controller 路由下來是控制器
7. 我們有IControllerFactory來創(chuàng)建Controller，提供createController()方法來返回IController
8. IController代表控制器，提供一個(gè)execute()方法來執(zhí)行控制器
9. 我們實(shí)現(xiàn)一個(gè)框架自帶的DefaultControllerFactory來以約定由于配置的方式根據(jù)約定規(guī)則以及路由數(shù)據(jù)RouteResult來找到IController并創(chuàng)建它
10. 我 們?yōu)镮Controller提供一個(gè)抽象實(shí)現(xiàn)，AbstractController，要求所有MVC框架的使用者創(chuàng)建的控制器需要繼承 AbstractController，在這個(gè)抽象實(shí)現(xiàn)中我們可以編寫一些便捷的API以便開發(fā)人員使用，比如view()方法、file()方法、 redirect()方法、json()方法、js()方法等等
11. action 找到了控制器后就是來找要執(zhí)行的方法了
12. 我們有IActionResult來代表Action返回的結(jié)果，提供一個(gè)execute()方法來執(zhí)行這個(gè)結(jié)果
13. 我們的框架需要實(shí)現(xiàn)一些自帶的IActionResult，比如ContentResult、ViewResult、FileResult、JsonResult、RedirectResult來對(duì)應(yīng)AbstractController的一些便捷方法
14. 再來定義一個(gè)IActionInvoker來執(zhí)行Action，提供一個(gè)invokeAction()方法
15. 我們需要實(shí)現(xiàn)一個(gè)DefaultActionInvoker以默認(rèn)的方式進(jìn)行方法的調(diào)用，也就是找到方法的一些IFilter按照一定的順序執(zhí)行他們，最后使用反射進(jìn)行方法的調(diào)用得到上面說的IActionResult并執(zhí)行它的execute()方法
16. filter 我們的框架很重要的一點(diǎn)就是便捷的過濾器
17. 剛才提到了IFilter，代表的是一個(gè)過濾器，我們提供IActionFilter對(duì)方法的執(zhí)行前后進(jìn)行過濾，提供IResultFilter對(duì)IActionResult執(zhí)行前后進(jìn)行過濾
18. 我們的IActionInvoker怎么找到需要執(zhí)行的IFilter呢，我們需要定義一個(gè)IFilterProvider來提供過濾器，它提供一個(gè)getFilters()方法來提供所有的IFilter的實(shí)例
19. 我 們的框架可以實(shí)現(xiàn)一些自帶的IFilterProvider，比如AnnotationFilterProvider通過掃描Action或 Controller上的注解來獲取需要執(zhí)行的過濾器信息；比如我們還可以實(shí)現(xiàn)GlobalFilterProvider，開發(fā)人員可以直接通過配置或代 碼方式告知框架應(yīng)用于全局的IFilter
20. 既然我們實(shí)現(xiàn)了多個(gè)IFilterProvider，我們自然需要有一個(gè)類來管理這些IFilterProvider，我們實(shí)現(xiàn)一個(gè)FilterProviders類并提供getFilters()方法（這和我們的Routes類來管理IRoute是類似的，命名統(tǒng)一）
21. view 各種IActionResult中最特殊最復(fù)雜的就是ViewResult，我們需要有一個(gè)單獨(dú)的包來處理ViewResult的邏輯
22. 我們需要有IViewEngine來代表一個(gè)模版引擎，提供一個(gè)getViewEngineResult()方法返回ViewEngineResult
23. ViewEngineResult包含視圖引擎尋找視圖的結(jié)果信息，里面包含IView和尋找的一些路徑等
24. IView自然代表的是一個(gè)視圖，提供render()方法（或者為了統(tǒng)一也可以叫做execute）來渲染視圖
25. 我 們的框架可以實(shí)現(xiàn)常見的一些模版引擎，比如FreemarkerViewEngine、VelocityViewEngine 等，VelocityViewEngine返回的ViewEngineResult自然包含的是一個(gè)實(shí)現(xiàn)IView的VelocityView，不會(huì)返回 其它引擎的IView
26. 同樣的，我們是不是需要一個(gè)ViewEngines來管理所有的IViewEngine呢，同樣也是實(shí)現(xiàn)findViewEngine()方法
27. common 這里可以放一些項(xiàng)目中各個(gè)模塊都要用到的一些東西
28. 比 如各種context，context代表的是執(zhí)行某個(gè)任務(wù)需要的環(huán)境信息，這里我們可以定義HttpContext、 ControllerContext、ActionContext和ViewContext，后者繼承前者，隨著MVC處理流程的進(jìn)行，View執(zhí)行時(shí)的 上下文相比Action執(zhí)行時(shí)的上下文信息肯定是多了視圖的信息，其它同理，之所以把這個(gè)信息放在common里面而不是放在各個(gè)模塊自己的包內(nèi)是因?yàn)檫@ 樣更清晰，可以一目了然各種對(duì)象的執(zhí)行上下文有一個(gè)立體的概念
29. 比如各種helper或utility

接下去就不再詳細(xì)闡述model、plugin等模塊的內(nèi)容了。

看到這里，我們來總結(jié)一下，我們的MVC框架在組織結(jié)構(gòu)上有著高度的統(tǒng)一：

• 如果xxx本身并無選擇策略，但xxx的創(chuàng)建過程也不是一個(gè)new這么簡(jiǎn)單的，可以由xxxFactory類來提供一個(gè)xxx
• 如果我們需要用到很多個(gè)yyy，那么我們會(huì)有各種yyyProvider（通過getyyy()方法）來提供這些yyy，并且我們需要有一個(gè)yyyProviders來管理這些yyyProvider
• 如果zzz的選擇是有策略性的，會(huì)按照需要選擇zzz1或zzzN，那么我們可能會(huì)有一個(gè)zzzs來管理這些zzz并且（通過findzzz()方法）來提供合適的zzz

同 時(shí)我們框架的相關(guān)類的命名也是非常統(tǒng)一的，可以一眼看出這是實(shí)現(xiàn)、還是抽象類還是接口；是提供程序，是執(zhí)行結(jié)果還是上下文。當(dāng)然，在將來的代碼實(shí)現(xiàn)過程中 很可能會(huì)把很多接口變?yōu)槌橄箢愄峁┮恍┠J(rèn)的實(shí)現(xiàn)，這并不會(huì)影響項(xiàng)目的主結(jié)構(gòu)。我們會(huì)在模式篇對(duì)框架常用的一些高層設(shè)計(jì)模式做更多的介紹。

到了這里，我們的項(xiàng)目里已經(jīng)有幾十個(gè)空的（抽象）類、接口了，其中也定義了各種方法可以把各個(gè)模塊串起來（各種find()方法和execute()方法），可以說整個(gè)項(xiàng)目的龍骨已經(jīng)建立起來了，這種感覺很好，因?yàn)槲覀冃睦锖苡械?，我們只需要在接下去的工作中做兩個(gè)事情：

• 實(shí)現(xiàn)各種DefaultXXX來走通主流程
• 實(shí)現(xiàn)各種IyyyProvider和Izzz接口來完善支線流程

#p#
走通主線流程

所謂走通主線流程，就是讓這個(gè)框架可以以一個(gè)HelloWorld形式跑起來，這就需要把幾個(gè)核心類的核心方法使用最簡(jiǎn)單的方式進(jìn)行實(shí)現(xiàn)，還是拿我們的MVC框架來舉例子：

• 從startup開始，可能需要實(shí)現(xiàn)ServletContextListener來動(dòng)態(tài)注冊(cè)我們框架的入口Servlet，暫且起名為DispatcherServlet吧，在這個(gè)類中我們需要走一下主線流程
• 調(diào)用Routes.findRoute()獲得IRoute
• 調(diào)用IRoute.getRouteResult()來獲得RouteResult
• 使用拿到的RouteResult作為參數(shù)調(diào)用DefaultControllerFactory.createController()獲得IController（其實(shí)也是AbstractController）
• 調(diào)用IController.execute()
• 在 config中創(chuàng)建一個(gè)IConfig作為一種配置方式，我們實(shí)現(xiàn)一個(gè)DefaultConfig，把各種默認(rèn)實(shí)現(xiàn)注冊(cè)到框架中去，也就是 DefaultRoute、DefaultControllerFactory、DefaultActionInvoker，然后把各種 IViewEngine加入ViewEngines
• 然后需要完成相關(guān)默認(rèn)類的實(shí)現(xiàn)：
• 實(shí)現(xiàn)Routes.findRoute()
• 實(shí)現(xiàn)DefaultRoute.getRouteResult()
• 實(shí)現(xiàn)DefaultControllerFactory.createController()
• 實(shí)現(xiàn)AbstractController.execute()
• 實(shí)現(xiàn)DefaultActionInvoker.invokeAction()
• 實(shí)現(xiàn)ViewResult.execute()
• 實(shí)現(xiàn)ViewEngines.findViewEngine()
• 實(shí)現(xiàn)VelocityViewEngine.getViewEngineResult()
• 實(shí)現(xiàn)VelocityView.render()

在這一步，我們并不一定要去觸碰filter和model這部分的內(nèi)容，我們的主線流程只是解析路由，獲得控制器，執(zhí)行方法，找到視圖然后渲染視圖。過濾器和視圖模型的綁定屬于增強(qiáng)型的功能，屬于支線流程，不屬于主線流程。

雖 然在這里我們說了一些MVC的實(shí)現(xiàn)，但本文的目的不在于教你實(shí)現(xiàn)一個(gè)MVC框架，所以不用深究每一個(gè)類的實(shí)現(xiàn)細(xì)節(jié)，這里想說的是，在前面的龍骨搭建完后， 你會(huì)發(fā)現(xiàn)按照這個(gè)龍骨為它加一點(diǎn)肉上去實(shí)現(xiàn)主要的流程是順理成章的事情，毫無痛苦。在整個(gè)實(shí)現(xiàn)的過程中，你可以不斷完善common下的一些 context，把方法的調(diào)用參數(shù)封裝到上下文對(duì)象中去，不但看起來清楚且符合開閉原則。到這里，我們應(yīng)該可以跑起來在設(shè)計(jì)階段做的那個(gè)示例網(wǎng)站的 HelloWorld功能了。

在這里還想說一點(diǎn)，有些人在實(shí)現(xiàn)框架的時(shí)候并沒有搭建龍骨的一步驟，直接以非OOP的方式實(shí)現(xiàn)了主線流程，這種方式有以下幾個(gè)缺點(diǎn)：

不容易做到SRP單一指責(zé)原則，你很容易把各種邏輯都集中寫在一起，比如大量的邏輯直接寫到了DispatcherServlet中，輔助一些Service或Helper，整個(gè)框架就肥瘦不勻，有些類特別龐大有些類特別小。
不容易做到OCP開閉原則，擴(kuò)展起來不方便需要修改老的代碼，我們期望的擴(kuò)展是實(shí)現(xiàn)新的類然后讓框架感知，而不是直接修改框架的某些代碼來增強(qiáng)功能。
很難實(shí)現(xiàn)DIP依賴倒置原則，即使你依賴的確實(shí)是IService但其實(shí)就沒意義，因?yàn)樗挥幸粋€(gè)實(shí)現(xiàn)，只是把他當(dāng)作幫助類來用罷了。

#p#
實(shí)現(xiàn)各種支線流程

我們想一下，對(duì)于這個(gè)MVC框架有哪些沒有實(shí)現(xiàn)的支線流程？其實(shí)無需多思考，因?yàn)槲覀冊(cè)诖罱埞请A段的設(shè)計(jì)已經(jīng)給了我們明確的方向了，我們只需要把除了主線之外的那些龍骨上也填充一些實(shí)體即可，比如：

1. 實(shí)現(xiàn)更多的IRoute，并注冊(cè)到Routes
2. 實(shí)現(xiàn)更多的IViewEngine，并注冊(cè)到ViewEngines
3. 實(shí)現(xiàn)必要的IFilterProvider以及FilterProviders，把IFilterProvider注冊(cè)到FilterProviders
4. 增強(qiáng)DefaultActionInvoker.invokeAction()方法，在合適的時(shí)候調(diào)用這些IFilter
5. 實(shí)現(xiàn)更多的IActionResult，并且為AbstractController實(shí)現(xiàn)更多的便捷方法來返回這些IActionResult
6. ……實(shí)現(xiàn)更多model模塊的內(nèi)容和plugin模塊的內(nèi)容

實(shí)現(xiàn)了這一步后，你會(huì)發(fā)現(xiàn)整個(gè)框架飽滿起來了，每一個(gè)包中不再是僅有的那些接口和默認(rèn)實(shí)現(xiàn)，而且會(huì)有一種OOP的爽快感，爽快感來源于幾個(gè)方面：

1. 面對(duì)接口編程抽象和多態(tài)的放心安心的爽快感
2. 為抽象類實(shí)現(xiàn)具體類享受到父類大量實(shí)現(xiàn)的滿足的爽快感
3. 實(shí)現(xiàn)了大量的接口和抽象類后充實(shí)的爽快感

我們?cè)賮砜偨Y(jié)一下之前說的那些內(nèi)容，實(shí)現(xiàn)一個(gè)框架的第一大步就是：

1. 設(shè)計(jì)一套合理的接口
2. 為框架進(jìn)行模塊劃分
3. 為框架搭建由抽象結(jié)構(gòu)構(gòu)成的骨架
4. 在這個(gè)骨架的基礎(chǔ)上實(shí)現(xiàn)一個(gè)HelloWorld程序
5. 為這個(gè)骨架的其它部分填充更多實(shí)現(xiàn)

經(jīng) 過這樣的一些步驟后可以發(fā)現(xiàn)這個(gè)框架是很穩(wěn)固的，很平衡的，很易于擴(kuò)展的。其實(shí)到這里很多人覺得框架已經(jīng)完成了，有血有肉，其實(shí)個(gè)人覺得只能說開發(fā)工作實(shí) 現(xiàn)了差不多30%，后文會(huì)繼續(xù)說，畢竟直接把這樣一個(gè)血肉之軀拿出去對(duì)外有點(diǎn)嚇人，我們需要為它進(jìn)行很多包裝和完善。

#p#

單元測(cè)試