Jfinal源碼分析-------數據庫連接創建和表-實體創建源碼分析

作WEB應用,假如你沒有任何對數據庫的操做,那麼你的應用將一無事處,爲何這麼說,由於你全部的業務數據沒有辦法存儲,因此數據庫在WEB應用當中是佔有至關重要的地位的.

那麼在Jfinal中,WEB應用他應該如何去實現的了?在實現這個過程中,咱們應該注意些什麼樣的細節了.在這些細節當中,又會有那些個坑在等着咱們了?

爲了能讓咱們更加好的去處理Jfinal與數據庫之間的關係,咱們今兒有必要去看看關於這方面的一些個事情. 咱們若是使用過SSH的話,應該對那些個XML文件配置會比較熟悉,好比Spring的類實例的注入,好比Hibernate的實體映射什麼的.一樣的,在Jfinal中也同樣,雖然咱們不用設置那麼多的選項,也不用去寫那些個XML文件,可是咱們仍是要作一些個必要的配置操做的. 首先,咱們要解決的就是數據庫鏈接的問題,若是有使用過JDBC的同窗們應該知道,咱們與數據庫操做的第一步就是使用Connection來鏈接咱們須要的數據庫,固然這些都是原理上的東西,後來咱們使用框架的時候又接觸了鏈接池,無論使用什麼原理去連接數據庫,咱們都須要緊緊的記住一點,咱們須要配置數據庫的地址和數據庫用戶名和密碼. 在DEMO中咱們應該看到一個在」WEB-INF」下面的a_little_config.txt文件，其實這個就是咱們數據庫的一些個配置，只不過是用這樣的形式來表演而已。

咱們就從這個地方開始分析，在Jfinal使用數據的時候，是在何時進行加載數據庫的配置，又在什麼狀況下進行實體和表進行對應的。

a_little_config.txt加載的時機 這個我以爲不用過多的說明了吧，猜都能猜到是在容器啓動的時候進行加載的。因此今天這個不是咱們討論的重點，重點在於，他怎麼加載的，以什麼樣的形式加載，在內存中他是以什麼樣的形式去表現的等等。 點開咱們的Jfinal.java，找到

<!-- lang: java -->
Config.configJFinal(jfinalConfig);

看到這個方法了吧，在這個方法裏面，就把咱們須要設置的全部Jfinal相關配置都作了一次設置。由於這個JfinalFilter也算是一個過濾器，他在容器啓動的時候，他只會去執行一次，這樣的操做，因此，他的做用是否是有點和WEB.xml中的做用相似？這下你是否是應該知道點什麼東西了？爲神馬JFinal要把這個Config對象中設立一個相似ConfigPlugin的方法，就是爲了讓你可以拓展你本身的Plugin，那你會問這樣和在配置WEB.Xml中的有什麼區別麼？額，由於你在xml中配置了這樣的配置：

<!-- lang: java -->
<filter-mapping>
	<filter-name>jfinal</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

由於你的url-pattern是咱們看到的這個，你若是在再這個地方陪其餘的東西，可能會出現衝突，具體什麼衝突，我沒有試過，因此，假如你想要拓展你本身的Plugin，我建議你仍是本身寫一個，完了再Config中進行加載。 回到咱們討論的話題： 在咱們進入了Config對象的時候，咱們能夠看到

<!-- lang: java -->
jfinalConfig.configConstant(constants);

jfinalConfig,此時的jfinalConfig就會調用你項目中的那個Config對象，而後進行多態調用。 你還記得你在你本身項目中的配置中有這麼一句話麼，

<!-- lang: java -->
loadPropertyFile("a_little_config.txt");

這個就是去調用你的那個數據庫的配置文件。 F3進入這個方法，而後你看看都有啥

<!-- lang: java -->
public Properties loadPropertyFile(String file) {
	...
            InputStream inputStream = null;
	String fullFile;	// String fullFile = PathUtil.getWebRootPath() + file;
	if (file.startsWith(File.separator))
		fullFile = PathKit.getWebRootPath() + File.separator + "WEB-INF" + file;
	else
		fullFile = PathKit.getWebRootPath() + File.separator + "WEB-INF" + File.separator + file;
            ...

}

看到這個函數了吧，他返回的是用Properties對象，也就是說，在內存當中，他是以這樣的方式去存的，不知道Properties對象的同窗請自行查看JavaSE的API，在這就很少說了 還有要說的就是，爲何這個配置文件須要放在WEB-INF當中，由於他代碼就是這麼寫的，而後你照着作就行了！ 看完這個之後，咱們看看

<!-- lang: java -->
public void configPlugin(Plugins me) {
C3p0Plugin c3p0Plugin = new C3p0Plugin(getProperty("jdbcUrl"), getProperty("user"),         getProperty("password").trim());
	me.add(c3p0Plugin);
	
	// 配置ActiveRecord插件
	ActiveRecordPlugin arp = new ActiveRecordPlugin(c3p0Plugin);
	me.add(arp);

... }

看到了吧，在Jfinal中，數據庫的連接是由這些個數據庫鏈接池組件來提供的，爲甚麼要這樣，提升性能，減小創建數據庫鏈接的時間，由於咱們知道，數據庫鏈接的創建是很消耗資源的。而後咱們設置這個數據庫鏈接池的一些個基本配置，什麼URL，什麼用戶名，什麼密碼之類的； 在咱們的數據庫鏈接池創建好之後，咱們就能夠爲ActiveRecord提供這些創建好的資源，而後就去創建數據庫的連接什麼的。 到此，咱們的第一步就作好了！數據庫的連接池已經有了！那麼如今咱們看第二部，表和實體映射，也就是咱們平時所說的ORM，嘿嘿… 看以下代碼：

<!-- lang: java -->
public ActiveRecordPlugin addMapping(String tableName, String primaryKey, Class<? extends Model<?>> modelClass) {
	tableMappings.add(new TableInfo(tableName, primaryKey, modelClass));
	return this;
}

AddMapping，就是添加實體與表的映射關係，其實你看就明白，這個ORM對應的關係是存儲在TableInfo中的。 經過咱們本身配置ORM，咱們就獲得了TableInfo實例，而後全部的Plugin都是去實現IPLUGIN的start()方法，去按照預約的方式去啓動相應的過程。 就那咱們這個ActiveRecordMapping來講，在咱們添加了ORM這關係之後，他確定會去執行start()方法。這樣在咱們容器啓動的過程，咱們就完成了實體和表的映射關係。 不信？有代碼爲證...

<!-- lang: java -->
public boolean start() {
	if (isStarted)
		return true;
	
	if (dataSourceProvider != null)
		dataSource = dataSourceProvider.getDataSource();
	
	if (dataSource == null)
		throw new RuntimeException("ActiveRecord start error: ActiveRecordPlugin need DataSource or DataSourceProvider");
	
	DbKit.setDataSource(dataSource);
	
	isStarted = true;
	return TableInfoBuilder.buildTableInfo(tableMappings);
}

上面的代碼告訴咱們，ActiveRecord啓動的過程當中，是TableInfoBuilder類來爲提供創建表-實體映射提供動力的。 至此 咱們這個數據庫連接創建和數據庫ORM創建的過程就算完成了！歡迎關注...後期將繼續深刻挖掘框架背後的故事。