ORM:object relation mapping,即對象關(guān)系映射，簡單的說就是對象模型和關(guān)系模型的一種映射。可以在PHP開發(fā)的業(yè)務(wù)邏輯層，通過數(shù)據(jù)訪問層來處理。ORM就是數(shù)據(jù)訪問層強(qiáng)大的一種解決方案。通過它，可以最大限度隔離業(yè)務(wù)邏輯層和數(shù)據(jù)源之間的耦合度
成都創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括南鄭網(wǎng)站建設(shè)、南鄭網(wǎng)站制作、南鄭網(wǎng)頁制作以及南鄭網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，南鄭網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到南鄭省份的部分城市，未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
不支持
在云領(lǐng)域我們常常會(huì)聽到一個(gè)詞：多租戶。這個(gè)詞在不同的語境中有著不同的含義。本文將介紹云平臺中的多租戶的概念以及實(shí)現(xiàn)多租戶支持的思路。
什么是租戶
剛開始接觸這個(gè)概念時(shí)，你肯定感覺“租戶”這個(gè)詞怪怪的。但假設(shè)我們換個(gè)詞，我相信你立即就有感覺了。這個(gè)詞就是“客戶”（這里的客戶指的就是商業(yè)上面的客戶）。
一個(gè)租戶就是一個(gè)客戶，比方我們開發(fā)的服務(wù)是給 XXX 企業(yè)使用的，那該企業(yè)就是我們的一個(gè)客戶/租戶；假設(shè)這個(gè)服務(wù)是面向互聯(lián)網(wǎng)的，那么使用該服務(wù)的每一個(gè)互聯(lián)網(wǎng)用戶都是一個(gè)客戶/租戶。
為什么須要多租戶支持
開發(fā)人員辛辛苦苦開發(fā)出一個(gè)服務(wù)。提供給了個(gè)人/企業(yè)使用，這樣就完事了么？當(dāng)然不應(yīng)該僅僅是這樣。我們開發(fā)出一個(gè)服務(wù)。最好是可以同一時(shí)候提供給多個(gè)個(gè)人/企業(yè)使用。并且這些客戶最好是共享同一套服務(wù)執(zhí)行時(shí)（Runtime），這樣可以大大減少服務(wù)的運(yùn)維成本：
服務(wù)執(zhí)行時(shí)假設(shè)分開，則運(yùn)維的成本與客戶數(shù)成正比（比方更新部署大量客戶的場景）
節(jié)省資源（將服務(wù)所需資源利用最大化：運(yùn)維團(tuán)隊(duì)統(tǒng)一、硬件使用）
另外，這樣也能夠減少服務(wù)的開發(fā)成本：
我們僅僅須要考慮怎樣實(shí)現(xiàn)單用戶的服務(wù)邏輯：業(yè)務(wù)邏輯相應(yīng)其全部客戶都是同樣的，不管什么客戶來使用，程序提供的服務(wù)都是一樣的。進(jìn)一步說，在業(yè)務(wù)層面我們開發(fā)這個(gè)服務(wù)時(shí)理論上不須要考慮多客戶支持，我們僅僅用關(guān)注該服務(wù)的業(yè)務(wù)邏輯怎樣實(shí)現(xiàn)
多客戶的管理功能能夠進(jìn)行統(tǒng)一：開發(fā)人員應(yīng)該不用考慮客戶管理功能，這部分應(yīng)該是由云平臺統(tǒng)一提供的
多租戶場景舉例
如果我們要開發(fā)的服務(wù)是一個(gè)博客平臺，這個(gè)服務(wù)是面向互聯(lián)網(wǎng)用戶的，每一個(gè)互聯(lián)網(wǎng)用戶都是我們的客戶（一個(gè)用戶就是一個(gè)租戶）。
在不支持多租戶的環(huán)境中，為了隔離每一個(gè)用戶的數(shù)據(jù)，至少我們在設(shè)計(jì)數(shù)據(jù)庫表時(shí)會(huì)考慮大多數(shù)表都存在一個(gè) user_id 字段。用于?CRUD?數(shù)據(jù)時(shí)使用該字段進(jìn)行用戶隔離。
比方如今的業(yè)務(wù)是“公布文章”。須要將文章數(shù)據(jù)保存在 article 表中，在實(shí)現(xiàn)時(shí)實(shí)際上我們關(guān)注了兩件事情：
CRUD：這是業(yè)務(wù)邏輯實(shí)現(xiàn)的一部分
用戶隔離：須要增加 user_id。做業(yè)務(wù)關(guān)聯(lián)
1 是“純”業(yè)務(wù)邏輯部分的實(shí)現(xiàn)。這是必須實(shí)現(xiàn)的；2 則是為了多用戶博客平臺而須要考慮的，這并非博客平臺本身的業(yè)務(wù)邏輯。這里假設(shè)能得到平臺的多租戶支持，就不用考慮第 2 點(diǎn)了。這樣能夠?qū)⒆⒁饬杏诘?1 點(diǎn)業(yè)務(wù)邏輯實(shí)現(xiàn)上，這是很典型的一個(gè)多租戶場景。
多租戶支持
我們能夠這樣理解多租戶支持：
從服務(wù)提供的角度看。我們開發(fā)的一個(gè)服務(wù)執(zhí)行時(shí)能夠同一時(shí)候提供給多個(gè)客戶使用。而且客戶之間的數(shù)據(jù)/狀態(tài)是保持隔離的
從服務(wù)使用的角度看，我和你能夠作為不同的客戶同一時(shí)候使用同一個(gè)執(zhí)行的服務(wù)，此時(shí)我們使用該服務(wù)完畢的業(yè)務(wù)是相互不影響的，就好像我們在使用自己獨(dú)享的服務(wù)一樣
那么這個(gè)服務(wù)就是支持多“客戶”的，即該服務(wù)支持多租戶。這里的“服務(wù)”能夠是應(yīng)用，能夠是 SaaS 平臺，也能夠是 PaaS 平臺。只是按眼下我們熟悉的云平臺看，應(yīng)用的多租戶支持應(yīng)該是最常規(guī)的。這是由于應(yīng)用面向的是用戶，這個(gè)群體是非常龐大的。
多租戶支持從實(shí)現(xiàn)的角度看。“是一種軟件架構(gòu)技術(shù)”，之所以強(qiáng)調(diào)它是屬于架構(gòu)層面是由于要實(shí)現(xiàn)它必須在做技術(shù)架構(gòu)時(shí)就要將其考慮在內(nèi)。
一種租戶模型
本文一開始我們提到使用“客戶”來置換“租戶”來理解租戶的含義。再從“商業(yè)”這個(gè)方面來看的話，我們不難發(fā)現(xiàn)租戶事實(shí)上就是其云環(huán)境中的商業(yè)模式實(shí)現(xiàn)的一部分。商業(yè)模式是多樣的。這意味著租戶的劃分也是多樣的。這里我們描寫敘述當(dāng)中一種可能的租戶棧：
應(yīng)用程序是提供給用戶使用的，對于應(yīng)用來說，用戶就是它的租戶（這一點(diǎn)業(yè)界比較統(tǒng)一）
SaaS 提供的服務(wù)是給應(yīng)用開發(fā)商使用的，對于 SaaS 來說，應(yīng)用開發(fā)商就是它的租戶
PaaS 提供的服務(wù)是給應(yīng)用系統(tǒng)使用的，對于 PaaS 來說。相關(guān)應(yīng)用的組合就是它的租戶
SaaS 和 PaaS 面向的是開發(fā)商、系統(tǒng)等非端用戶角色。這一部分通常是由云平臺開發(fā)人員決定的（捆綁商業(yè)模式）。特別是私有/企業(yè)云平臺一般不會(huì)考慮形如“在 PaaS 平臺上支持執(zhí)行多個(gè) SaaS 平臺”這種場景。所以以下我們很多其它的是環(huán)繞“應(yīng)用對多租戶支持”進(jìn)行討論。
應(yīng)用多租戶
應(yīng)用多租戶的使用場景前面已經(jīng)介紹過了。如今如果我們是一個(gè)云平臺開發(fā)人員，為了滿足支持應(yīng)用支持多租戶的需求，在云平臺中我們須要提供以下幾個(gè)支持：
租戶管理：CRUD，統(tǒng)計(jì)
租戶隔離/共享的服務(wù)：隊(duì)列、緩存、數(shù)據(jù)庫等
租戶隔離的統(tǒng)計(jì)：日志、配額
這些支持能夠分為兩類：
租戶的管理：不會(huì)直接面向應(yīng)用的端用戶。面向的是應(yīng)用的運(yùn)維。平臺應(yīng)該提供詳細(xì)實(shí)現(xiàn)
租戶數(shù)據(jù)/狀態(tài)的隔離：從請求開始就應(yīng)該能夠區(qū)分這個(gè)請求是來自于哪個(gè)租戶，請求處理時(shí)在調(diào)用鏈路上也須要帶上租戶上下文。數(shù)據(jù)的存取是依照租戶隔離的。調(diào)用平臺提供的服務(wù)時(shí)也是租戶隔離的
第 1 點(diǎn)比較easy實(shí)現(xiàn)。這是一個(gè)業(yè)務(wù)模型方面的問題，能夠依據(jù)業(yè)務(wù)域來抽象租戶模型，比方企業(yè)應(yīng)用通常是依照“組織機(jī)構(gòu)”來區(qū)分租戶的；
第 2 點(diǎn)是一個(gè)純技術(shù)的需求。須要在平臺技術(shù)實(shí)現(xiàn)上支持按“租戶”的執(zhí)行時(shí)隔離，我們強(qiáng)調(diào)的是隔離，由于在實(shí)現(xiàn)時(shí)我們要達(dá)到的目標(biāo)就是隔離，僅僅只是這里是按租戶（租戶僅僅是一個(gè)商業(yè)概念，技術(shù)層面我們最好能夠?qū)⑵溥M(jìn)行抽象。盡量減小商業(yè)模式多樣化對技術(shù)架構(gòu)的沖擊）。我們能夠?qū)⒆鈶粲成涞揭粋€(gè)抽象概念上，這個(gè)抽象概念能夠?qū)崿F(xiàn)我們的隔離需求。
1、PHP動(dòng)態(tài)語言執(zhí)行過程：拿到一段代碼后，經(jīng)過詞法解析、語法解析等階段后，源程序會(huì)被翻譯成一個(gè)個(gè)指令（opcodes）,然后ZEND虛擬機(jī)順次執(zhí)行這些指令完成操作。PHP本身是用C實(shí)現(xiàn)的，因此最終調(diào)用的也是C的函數(shù)，實(shí)際上，我們可以把PHP看做一個(gè)C開發(fā)的軟件。
2、PHP的4層運(yùn)行體系：
（1）Zend引擎：Zend整體用純C實(shí)現(xiàn)，是PHP的內(nèi)核部分，他將PHP代碼翻譯（詞法、語法解析等一系列編譯過程）為可執(zhí)行opcode的處理并實(shí)現(xiàn)相應(yīng)的處理方法、實(shí)現(xiàn)了基本的數(shù)據(jù)結(jié)構(gòu)（如：hashtable、OO）、內(nèi)存分配機(jī)制及管理、提供了相應(yīng)的api方法供外部調(diào)用，是一切的核心，所有的外圍功能均圍繞Zend實(shí)現(xiàn)。
（2）Extensions：圍繞著Zend引擎，extensions通過組件式的方式提供各種基礎(chǔ)服務(wù)，我們常見的各種內(nèi)置函數(shù)（array系列）、標(biāo)準(zhǔn)庫等都是通過extension來實(shí)現(xiàn)，用戶也可以根據(jù)需要實(shí)現(xiàn)自己的extension的典型應(yīng)用）。
（3）Sapi：Sapi全稱ServerApplicationProgrammingInterface，也就是服務(wù)端應(yīng)用編程接口，Sapi通過一系列鉤子函數(shù)，使得PHP可以和外圍交互數(shù)據(jù)，這是PHP非常優(yōu)雅和成功的設(shè)計(jì)，通過sapi成功的將PHP本身和上層應(yīng)用解耦隔離，PHP可以不再考慮如何針對不同應(yīng)用進(jìn)行兼容，而應(yīng)用本身也可以針對自己的特點(diǎn)實(shí)現(xiàn)不同的處理方式。
（4）上層應(yīng)用：這就是我們平時(shí)編寫的PHP程序，通過不同的spai方式得到各種各樣的應(yīng)用模式，如何通過webserver實(shí)現(xiàn)web應(yīng)用、在命令行下已腳本方式運(yùn)行等等。
在這個(gè)互聯(lián)網(wǎng)高度發(fā)達(dá)的時(shí)代，許多應(yīng)用的用戶動(dòng)輒成百上千萬，甚至上億。為了支持海量用戶的訪問，應(yīng)用服務(wù)器集群這種水平擴(kuò)展的方式是最常用的。這種情形下，就會(huì)涉及到許多單機(jī)環(huán)境下完全不需要考慮的問題，這其中session的創(chuàng)建、共享和存儲(chǔ)是最常見之一。
在單機(jī)環(huán)境中，Session的創(chuàng)建和存儲(chǔ)都是由同一個(gè)應(yīng)用服務(wù)器實(shí)例來完成，而存儲(chǔ)也僅是內(nèi)存中，最多會(huì)在正常的停止服務(wù)器的時(shí)候，把當(dāng)前活動(dòng)的Session鈍化到本地，再次啟動(dòng)時(shí)重新加載。
而多個(gè)實(shí)例之間，Session數(shù)據(jù)是完全隔離的。而為了實(shí)現(xiàn)Session的高可用，多實(shí)例間數(shù)據(jù)共享是必然的，下面我們以Redis 的SessionManager實(shí)現(xiàn)多Tomcat實(shí)例Session共享的配置為例，我們來梳理下一般session共享的流程：
添加具體要使用的manager的Jar文件及其依賴
redis session manager依賴jedis, commons-pool, commons-pool2
對應(yīng)版本的redis session manager的jar文件
在TOMCAT_HOME/conf/context.xml中增加如下配置
Valve className="com.radiadesign.catalina.session.RedisSessionHandlerValve" /
Manager className="com.radiadesign.catalina.session.RedisSessionManager"
host="localhost"
port="6379" database="0"
maxInactiveInterval="30" /
其中host和port等替換為對應(yīng)的配置信息
啟動(dòng)多個(gè)Tomcat實(shí)例，以自帶的examples應(yīng)用為例進(jìn)行驗(yàn)證
訪問examples應(yīng)用的servlets/servlet/SessionExample，
在頁面中添加數(shù)據(jù)到session中，并查看頁面上對應(yīng)的session信息
訪問另一個(gè)實(shí)例上相同應(yīng)用的頁面，查看session信息，兩者應(yīng)該是一致的
使用redis-cli查看redis中存儲(chǔ)的對應(yīng)數(shù)據(jù)，相應(yīng)的sessionId對應(yīng)的數(shù)據(jù)已經(jīng)保存了下來
以上是一個(gè)基本的配置過程，而在這些配置與驗(yàn)證的步驟中，第二步是核心邏輯實(shí)現(xiàn)。 前面的文章，曾介紹過Tomcat的Valve，在請求處理時(shí)，Pipeline中的各個(gè)Valve的invoke方法會(huì)依次執(zhí)行。Tomcat的AccessLogValve介紹
此處的session處理，就是以一個(gè)自定義Valve的形式進(jìn)行的。關(guān)于Session的文章，前面也寫過幾篇，會(huì)附在結(jié)尾處。
以下是RedisSessionhandlerValve的invoke方法，我們看，主要是在Valve執(zhí)行后進(jìn)行Session的存儲(chǔ)或移除。
public void invoke(Request request, Response response) {
try {
getNext().invoke(request, response);
} finally {
final Session session = request.getSessionInternal(false);
storeOrRemoveSession(session);
manager.afterRequest();
}
}
而session的保存和移除又是通過manager執(zhí)行的。 manager.save(session); manager.remove(session);
這里，manager就是前面定義的RedisSessionManager。默認(rèn)單實(shí)例情況下，我們使用的都是StandardManager，對比一下兩者，標(biāo)準(zhǔn)的Manager對于session的創(chuàng)建和刪除，都會(huì)調(diào)到其父類ManagerBase中相應(yīng)的方法，
public void add(Session session) {
sessions.put(session.getIdInternal(), session);
int size = getActiveSessions();
if( size maxActive ) {
synchronized(maxActiveUpdateLock) {
if( size maxActive ) {
maxActive = size;
}
}
}
}
public void remove(Session session, boolean update) {
if (session.getIdInternal() != null) {
sessions.remove(session.getIdInternal());
}
}
我們來看，由于其只保存在內(nèi)存的Map中protected MapString, Session sessions = new
ConcurrentHashMap()，每個(gè)Tomcat實(shí)例都對于不同的map，多個(gè)實(shí)例間無法共享數(shù)據(jù)。
對應(yīng)到RedisSessionManager對于session的處理，都是直接操作redis，基本代碼是下面這個(gè)樣：
public void save(Session session) throws IOException {
Jedis jedis = null;
Boolean error = true;
try {
RedisSession redisSession = (RedisSession) session;
Boolean sessionIsDirty = redisSession.isDirty();
redisSession.resetDirtyTracking();
byte[] binaryId = redisSession.getId().getBytes();
jedis = acquireConnection();
if (sessionIsDirty || currentSessionIsPersisted.get() != true) {
jedis.set(binaryId, serializer.serializeFrom(redisSession));
}
currentSessionIsPersisted.set(true);
jedis.expire(binaryId, getMaxInactiveInterval());
} }
移除時(shí)的操作是這樣的
public void remove(Session session, boolean update) {
Jedis jedis = null;
Boolean error = true;
log.trace("Removing session ID : " + session.getId());
try {
jedis = acquireConnection();
jedis.del(session.getId());
error = false;
} finally {
if (jedis != null) {
returnConnection(jedis, error);
}
}
}
而此時(shí)，多個(gè)Tomcat實(shí)例都讀取相同的Redis，session數(shù)據(jù)是共享的，其它實(shí)例的初始請求過來時(shí)，由于會(huì)執(zhí)行findSession的操作，此時(shí)會(huì)從Redis中加載session，
public Session findSession(String id) throws IOException {
RedisSession session;
if (id == null) {
session = null;
currentSessionIsPersisted.set(false);
} else if (id.equals(currentSessionId.get())) {
session = currentSession.get();
} else {
session = loadSessionFromRedis(id); // 看這里，會(huì)從redis中l(wèi)oad
if (session != null) {
currentSessionIsPersisted.set(true);
}
}
currentSession.set(session);
currentSessionId.set(id);
return session;
}
從而可以保證在一個(gè)實(shí)例被切換后，另外的實(shí)例可以繼續(xù)響應(yīng)同一個(gè)session的請求。
以上即為Redis實(shí)現(xiàn)session共享高可用的一些關(guān)鍵內(nèi)容。有興趣的朋友可以看下通過Memcached實(shí)現(xiàn)高可用，也是這個(gè)原理。順著這個(gè)思路，如果你有將Session存儲(chǔ)在其它地方的需求時(shí)，完全可以寫一個(gè)出來，自己動(dòng)手，豐衣足食。
總結(jié)一下，我們是通過自定義的Valve來實(shí)現(xiàn)請求后session的攔截，同時(shí)，使用自定義的SessionManager,來滿足不同的session創(chuàng)建與存儲(chǔ)的需求。而至于是存儲(chǔ)在Redis/Memcached中，還是存儲(chǔ)在DB中，只是位置的區(qū)別。原理，是一致的。
樓主你可以考慮MYSQL的事務(wù)處理功能。
一般來說，事務(wù)是必須滿足4個(gè)條件（ACID）
原子性（Autmic）：事務(wù)在執(zhí)行性，要做到“要么不做，要么全做！”，就是說不允許事務(wù)部分得執(zhí)行。即使因?yàn)楣收隙故聞?wù)不能完成，在rollback時(shí)也要消除對數(shù)據(jù)庫得影響！
一致性（Consistency）：事務(wù)得操作應(yīng)該使使數(shù)據(jù)庫從一個(gè)一致狀態(tài)轉(zhuǎn)變倒另一個(gè)一致得狀態(tài)！就拿網(wǎng)上購物來說吧，你只有即讓商品出庫，又讓商品進(jìn)入顧客得購物籃才能構(gòu)成事務(wù)！
隔離性（Isolation）：如果多個(gè)事務(wù)并發(fā)執(zhí)行，應(yīng)象各個(gè)事務(wù)獨(dú)立執(zhí)行一樣！
持久性（Durability）：一個(gè)成功執(zhí)行得事務(wù)對數(shù)據(jù)庫得作用是持久得，即使數(shù)據(jù)庫應(yīng)故障出錯(cuò)，也應(yīng)該能夠恢復(fù)！
說白了就是某一個(gè)用戶進(jìn)行兌換操作的時(shí)候，就把對應(yīng)的數(shù)據(jù)表鎖定死，只有等操作完成后才解鎖。
php單一入口模式可謂是現(xiàn)在一種比較流行的大型web應(yīng)用開發(fā)模式，比如當(dāng)前比較流行的一些php開發(fā)框架，zend，thinkphp，qeephp，還有cakephp
等他們都是采用的單一入口模式的。本文將就什么是單一入口模式，單一入口模式有哪些優(yōu)點(diǎn)以缺點(diǎn)做一下研究。
什么是單一入口?
在解釋什么是單一入口之前，先說說與之對應(yīng)的多入口。多入口即通過訪問不同的 php 文件運(yùn)行對應(yīng)的功能。比如剛開始學(xué)習(xí) php
的時(shí)候，我們做一個(gè)項(xiàng)目通常都會(huì)如下這樣做：
index.php - 網(wǎng)站首頁
list.php?page=5 - 內(nèi)容列表頁
info.php?id=12 - 內(nèi)容詳細(xì)頁
login.php - 用戶登錄頁
對于這個(gè)項(xiàng)目來說，這其實(shí)就是一個(gè)多入口。
那么單一入口的應(yīng)用程序就是說用一個(gè)文件處理所有的HTTP請求，例如不管是內(nèi)容列表頁，用戶登錄頁還是內(nèi)容詳細(xì)頁，都是通過從瀏覽器訪問 index.php
文件來進(jìn)行處理的，這里這個(gè) index.php 文件就是這個(gè)應(yīng)用程序的單一入口。
php 是如何實(shí)現(xiàn)單一入口的呢?
很簡單，一般單一入口程序都是在訪問index.php時(shí)附帶一個(gè)特定的參數(shù)。例如：index.php?action=list 就可以定義為訪問內(nèi)容列表頁，而
index.php?action=info 則可以定義為訪問內(nèi)容詳細(xì)頁等，具體實(shí)現(xiàn)代碼如下：
//從url中取出action參數(shù)，如果沒有提供action參數(shù)，就設(shè)置一個(gè)默認(rèn)的'index'作為參數(shù)
$action=$_GET['action']==''?'index':$_GET['action'];
//根據(jù)$action參數(shù)調(diào)用不同的代碼文件，從而滿足單一入口實(shí)現(xiàn)對應(yīng)的不同的功能
include('files/'.$action.'.php');
以上這個(gè)就實(shí)現(xiàn)了一個(gè)最簡單的單一入口模式程序，當(dāng)然真正的單一入口模式會(huì)比這個(gè)要復(fù)雜很多。但只要懂得如何合理組織各個(gè)功能的處理代碼并遵循一定的步驟，也可以輕松的解決掉這個(gè)難題，下面就一個(gè)后臺的例子來做一下說明：
比如我們現(xiàn)在要做一個(gè)新聞管理的后臺。那么首先，對于應(yīng)用程序的功能要做出一個(gè)合理的分解。例如后臺的新聞欄目可能包含“添加新聞”、“編輯新聞”、“刪除新聞”等多個(gè)功能。這時(shí)我們就可以將這一組邏輯上關(guān)聯(lián)的功能組合到一個(gè)功能模塊中，稱為“新聞管理”模塊。
按照上面的方法整理完應(yīng)用程序的功能，我們就會(huì)得到多個(gè)功能模塊，而每個(gè)模塊又是由多個(gè)功能組成(實(shí)際上，即便不是單一入口應(yīng)用程序，功能的整理也是必須的步驟)。
整理完功能后，我們就需要確定如何存放各個(gè)功能的代碼。這里我推薦兩種方式：
1、每個(gè)功能模塊一個(gè)子目錄，目錄里的每一個(gè)文件就是一個(gè)功能的實(shí)現(xiàn)代碼。
這
種方式的好處是每個(gè)功能的代碼都互相隔離，非常便于多人協(xié)作。缺點(diǎn)是每個(gè)功能之間共享代碼和數(shù)據(jù)不那么方便。例如新聞管理模塊中的所有功能都需要一個(gè)“取
出新聞欄目記錄”的功能，那么采用這種多個(gè)獨(dú)立文件的組織方式，“取出新聞欄目記錄”就只能寫在另一個(gè)文件中，然后由需要該功能的文件include
進(jìn)去。
2、每個(gè)模塊一個(gè)文件，模塊中的每個(gè)功能寫成一個(gè)函數(shù)或者一個(gè)類方法。
好處不用多說了，非常便于共享代碼和數(shù)據(jù)。缺點(diǎn)就是如果幾個(gè)人同時(shí)改，容易發(fā)生沖突。不過借助版本控制軟件和差異比較合并工具，沖突還是很容易解決的。
單一入口應(yīng)用程序?qū)?yīng)多入口有哪些優(yōu)勢呢?
單
一入口應(yīng)用程序的所有http請求都是通過index.php接收并轉(zhuǎn)發(fā)到功能代碼中去的，所以在index.php里面就能完成許多實(shí)際工作(所有頁面
都需要做的且都一樣的工作)。比如進(jìn)行集中的安全性檢查，訪問統(tǒng)計(jì)等等，如果不是單一入口，那么開發(fā)者就必須記得在每一個(gè)文件的開始加上安全性檢查代碼，
當(dāng)然，你也許會(huì)說，多入口的安全性檢查可以寫到另一個(gè)文件中，然后include一下就可以了。但實(shí)際針對一個(gè)相對較大型一點(diǎn)的應(yīng)用項(xiàng)目，在幾十個(gè)文件中
保持頭部的幾個(gè)include都一致可不是一件讓人省心的事。
與安全性檢查類似。在入口里，我們還可以對url參數(shù)和post進(jìn)行必要的檢查和特殊字符過濾、記錄日志、訪問統(tǒng)計(jì)等等各種可以集中處理的任務(wù)。這樣就可以看出，由于這些工作都被集中到了index.php來完成，可以減輕我們維護(hù)其他功能代碼的難度。
單一入口應(yīng)用程序的缺點(diǎn)?
任何事情都有兩面性，單一入口應(yīng)用程序也不例外。由于所有http請求都是訪問 index.php ，所以程序的 url
看起來不那么美觀，特別是對搜索引擎來說不太友好。比如下面這個(gè) url：
;action=index
我們知道這種URl不太方便記憶，而且搜索引擎不認(rèn)它是一個(gè)正常的 URL，當(dāng)然是相比下面這種 URl 來說的：
不過這個(gè)也不是什么大問題，可以采用url重寫、PATHINFO等方式就可以輕松解決這個(gè)問題。
OK，單一入口模式就寫這么多了，當(dāng)然要想深刻理解單一模式，最好的辦法還是自己嘗試著用單一入口模式寫一個(gè)小應(yīng)用出來深刻體會(huì)一下。
本文地址：
重慶分公司
重慶分公司
