記得幾多個月前，正在一次北京博客園俱樂部的流動上，最后一個環(huán)節(jié)是話題自由探討。便是提幾多個話題，而后各人各自參預感趣味的話題小組，停行自由探討。其時金澀海洋同學提出了一個話題——“什么是業(yè)務邏輯”。其時我和各人探討ASP.NET MxC的相關(guān)話題去了，就沒能參預“業(yè)務邏輯”組的探討，比較遺憾。
其真，一段光陽內(nèi)，我腦子里對“業(yè)務邏輯”的觀念也是很是暗昧的。但正在不停地瀏覽、考慮和理論歷程中，那個觀念及其相關(guān)的內(nèi)容才正在我腦子里漸漸明晰。我想，不少冤家興許也對那個觀念不是很理解，所以甘愿承諾聯(lián)結(jié)既有量料和原人的考慮，總結(jié)一篇對于業(yè)務邏輯的概述性文章，一則取冤家們分享會商，二則也是為原人對業(yè)務邏輯的進修作一個總結(jié)和提升。因為我還不敢說對業(yè)務邏輯內(nèi)涵及外延了解的很是豐裕，所以文中如有欠妥之處，還請各位不用客氣，只管攻訐就好！
內(nèi)容概要
===================前篇=====================
前言
內(nèi)容概要
1、我把業(yè)務邏輯丟了！——找回損失的業(yè)務邏輯
2、細說業(yè)務邏輯
2.1、業(yè)務邏輯到底是什么
2.2、業(yè)務邏輯的構(gòu)成構(gòu)造
2.2.1、規(guī)模真體（Domain Entity）
2.2.2、業(yè)務規(guī)矩（Business Rules）
2.2.3、完好性約束（xalidation）
2.2.4、業(yè)務流程及工做流（Business Processes and Workflows）
2.3、業(yè)務邏輯層職責相關(guān)爭議
2.3.1、爭議一：數(shù)據(jù)的格局化
2.3.2、爭議二：數(shù)據(jù)正當性及完好性驗證
2.3.3、爭議三：CRUD
2.3.4、爭議四：存儲歷程
===================后篇=====================
3、業(yè)務邏輯的架構(gòu)形式及真現(xiàn)
3.1、Transcaton Script
3.1.1、概述
3.1.2、闡明
3.1.3、.NET平臺真現(xiàn)示例
3.2、Table Module
3.2.1、概述
3.2.2、闡明
3.2.3、.NET平臺真現(xiàn)示例
3.3、ActiZZZe Record
3.3.1、概述
3.3.2、闡明
3.3.3、.NET平臺真現(xiàn)示例
3.4、Domain Model
3.4.1、概述
3.4.2、闡明
3.4.3、.NET平臺真現(xiàn)示例
3.5、各類架構(gòu)形式的比較及選擇
4、完畢語
參考文獻
1、我把業(yè)務邏輯丟了！——找回損失的業(yè)務邏輯
相信冤家們根柢都是軟件開發(fā)人員。不管身處什么職位，咱們的工做都有一個怪異的目的——制做軟件產(chǎn)品。而所謂的軟件產(chǎn)品，一定是正在某個規(guī)模內(nèi)去真現(xiàn)某些業(yè)務。如此看來，“業(yè)務邏輯”原應和“軟件產(chǎn)品”是緊緊綁正在一起的，沒有業(yè)務邏輯，何來軟件產(chǎn)品？
但是，我發(fā)現(xiàn)一個獨特的景象，一說業(yè)務邏輯，不少人就無奈造成明晰地印象。譬喻，規(guī)范的三層架構(gòu)：默示層、業(yè)務邏輯層和數(shù)據(jù)會見層，一提到默示層或數(shù)據(jù)會見層，各人腦子里即刻能孕育發(fā)作出明晰的觀念，但一提到業(yè)務邏輯層，就有點暗昧了，大概徹底不曉得其是什么，大概有個暗昧的皮相，但對其詳細的職責、構(gòu)造不是很清楚。實是奇了怪了！咱們天天和業(yè)務邏輯打交道，搞不清業(yè)務邏輯是什么。
應付那個獨特的景象，我思前想后，聯(lián)結(jié)原身的經(jīng)驗（我也曾很長光陽搞不清業(yè)務邏輯），末于弄清楚了其起因——那和咱們接觸那個觀念的門路和認知構(gòu)造有莫大干系。
不曉得有幾多多人和我一樣，初度接觸“業(yè)務邏輯”那個觀念是從分層架構(gòu)中的“業(yè)務邏輯層”觀念初步的，我相信不正在少數(shù)。工作壞就壞正在那里！為了讓冤家們曲不雅寓目清“業(yè)務邏輯”的觀念是怎樣被咱們丟掉的，請各人看一個圖，那個圖展示了不少人對“業(yè)務邏輯”的認知歷程。
圖1-1、狹義的認知折成歷程
如圖1-1所示，咱們先接觸了分層架構(gòu)，而后對每個層孕育發(fā)作了初階的認識。此中，由于默示層和數(shù)據(jù)會見層的代碼職責明晰明白，根柢能準確認識。但是，由于咱們接觸的分層架構(gòu)的Demo大多業(yè)務極其簡略，又根柢是CRUD收配會合型的業(yè)務。所以，咱們腦子中就孕育發(fā)作了疑問：那個所謂的業(yè)務邏輯層是干什么的？怎樣就簡略封拆了一下數(shù)據(jù)會見層的收配？那有存正在的必要嗎？由于有了那種“先入為主”的誤導，使得不少冤家腦中將“業(yè)務邏輯”和“業(yè)務邏輯層”兩個觀念稠濁了，始末想不大皂那東西到底是什么，作什么用的。再加上不少冤家所看的、所作的系統(tǒng)都是CRUD收配會合型的，就造成為了“業(yè)務邏輯貌似便是對數(shù)據(jù)會見收配的簡略封拆”那一全面觀念。
到底那一觀念有沒有錯呢？其真沒錯，因為正在簡略的、CRUD收配會合型軟件中，業(yè)務邏輯根柢便是對數(shù)據(jù)會見簡略的封拆。但是，無錯不代表片面，那是一種狹義的業(yè)務邏輯了解，而且是狹義中的狹義。為什么那么說呢？因為咱們不僅是正在“業(yè)務邏輯層”那么一個狹義領(lǐng)域內(nèi)去了解業(yè)務邏輯，而且還是CRUD會合型收配那種“很是瘦”的業(yè)務邏輯層領(lǐng)域內(nèi)去了解，所以，可謂是正在狹義的根原上的狹義。
當咱們把那么一個“狹義中的狹義業(yè)務邏輯”取“業(yè)務邏輯”等同起來時，誤會、渺茫、猜忌、不屑就顯現(xiàn)了。那就宛如，給你一只溫柔的哈巴狗，還是病怏怏的、垂頭喪氣的小哈巴狗，而你把那只“病怏怏的小哈巴狗”取“狗”的觀念等同起來了。這么你一定就會為有人養(yǎng)狗看家和差人養(yǎng)狗當警犬抓奸人而猜忌：那東西那么弱小，我一腳就踩死了，怎樣弄用來看家和抓奸人呢？進而可能會孕育發(fā)作“狗狗無用論”，“狗狗制品”等不雅見地。雖然，正在現(xiàn)真中，很少有人只見過小哈巴狗而沒見過狼狗等其他狗類，所以，故事中的誤會對“狗”正常是不存正在的。但正在現(xiàn)真中，簡曲有不少人只見過業(yè)務邏輯中的“小哈巴狗”，卻沒有見過業(yè)務邏輯中的“狼狗”、“藏獒”，所以，那種誤會正在對“業(yè)務邏輯”的了解上寬泛存正在。
這么，廣義的狀況畢竟后果是怎樣樣的？請看下圖。
圖1-2、廣義的認知折成歷程
（留心！凡是不出格注明，下文中所有“數(shù)據(jù)”一詞都指須要恒暫化的數(shù)據(jù)，而不蘊含內(nèi)存中的久時數(shù)據(jù)。請各位注意。）
如圖1-2所示，廣義的認知折成應當是那樣的：軟件產(chǎn)品都是正在某個規(guī)模內(nèi)真現(xiàn)某些特定業(yè)務，所以，軟件產(chǎn)品天生應當折成為界面交互局部和業(yè)務邏輯局部，此中業(yè)務邏輯局部是軟件產(chǎn)品的焦點，它客不雅觀存正在于軟件產(chǎn)品內(nèi)部，但是無奈對運用者孕育發(fā)作曲不雅觀刺激，因而業(yè)務邏輯不能取運用者間接交互。而界面交互局部是業(yè)務邏輯取運用者停行交流的接口，運用者通過界面交互局部，取業(yè)務停行交流，從而使得軟件產(chǎn)品闡揚其做用。
而正在詳細真現(xiàn)系統(tǒng)時，界面交互局部演化成默示層，業(yè)務邏輯局部演化成業(yè)務邏輯層。所以，可以認為，數(shù)據(jù)會見層不是軟件產(chǎn)品作做演化的間接產(chǎn)物，之所以顯現(xiàn)數(shù)據(jù)會見層，是因為某些產(chǎn)品的業(yè)務屬于“數(shù)據(jù)收配會合型”業(yè)務，為了真現(xiàn)斷絕、復用等宗旨，架構(gòu)師從業(yè)務邏輯中分袂出了頻繁運用的數(shù)據(jù)會見業(yè)務，造成為了徑自的數(shù)據(jù)會見層。從廣義來說，可以認為數(shù)據(jù)會見隸屬于業(yè)務邏輯，因為，數(shù)據(jù)會見收配真際上也是業(yè)務邏輯的一局部。
總結(jié)一下幾多個要點：（那幾多個要中的業(yè)務邏輯均指廣義業(yè)務邏輯）
1）軟件產(chǎn)品作做的可分為界面交互局部和業(yè)務邏輯局部。
2）從空間構(gòu)造上看，業(yè)務邏輯和數(shù)據(jù)會見不是并列干系，而是隸屬干系——數(shù)據(jù)會見隸屬于業(yè)務邏輯。盡管正在詳細系統(tǒng)真現(xiàn)層面，數(shù)據(jù)會見層和業(yè)務邏輯層是并列存正在，但從觀念素量層面上闡明，兩者是隸屬干系。
3）從光陽構(gòu)造上看，應當是先有業(yè)務邏輯的觀念，才無數(shù)據(jù)會見的觀念。業(yè)務邏輯衍生自軟件自身，數(shù)據(jù)會見衍生自業(yè)務邏輯。
4）因為業(yè)務邏輯是軟件產(chǎn)品作做的一局部，所以領(lǐng)有業(yè)務邏輯是軟件產(chǎn)品的必要條件（讀者可以試著舉出一個不包孕業(yè)務邏輯的軟件）。但是一個軟件可以沒無數(shù)據(jù)會見，如“計較器”、“不帶存檔的小游戲”等。
操做以上論述要點和認知折成，冤家們可以嘗嘗正在腦中從頭修筑狹義和廣義“業(yè)務邏輯”的觀念?？茨懿荒馨言蹅儊G掉的業(yè)務邏輯觀念找回來離去。對于業(yè)務邏輯更多的細節(jié)，將正在下文中探討。
2、細說業(yè)務邏輯
2.1、業(yè)務邏輯到底是什么
正在第一大節(jié)里說了這么多，相信各位根柢曾經(jīng)造成“業(yè)務邏輯”的觀念了。假如我正在那里再簡便什么，我不嫌累各位也要嫌煩了。所以，那里我僅給出兩個界說。
廣義上的責任邏輯——軟件自身固有的一種品性，作做存正在于軟件產(chǎn)品內(nèi)部，是軟件具有的正在某個業(yè)務規(guī)模內(nèi)的邏輯，是軟件的焦點和魂靈。軟件產(chǎn)品除界面和交互外的一切都可看做是廣義業(yè)務邏輯。
狹義上的業(yè)務邏輯——等同于分層架構(gòu)中“業(yè)務邏輯層”的職責，是軟件中辦理取業(yè)務相關(guān)任務的局部，正常狹義上的業(yè)務邏輯不包孕數(shù)據(jù)恒暫化，而只關(guān)注規(guī)模內(nèi)的相關(guān)業(yè)務。
應付以上兩種界說，欲望冤家們不要分裂開來看，而 要辯證統(tǒng)一的去看，那樣，威力構(gòu)建一個完好而辯證統(tǒng)一的“業(yè)務邏輯”觀念。正在下文中，將不再明白區(qū)分狹義和廣義，“業(yè)務邏輯”一詞將代表兩者的辯證統(tǒng)一體。
2.2、業(yè)務邏輯的構(gòu)成構(gòu)造
業(yè)務邏輯做為一個高層次觀念，其內(nèi)正在構(gòu)造也是很是富厚的，下面咱們深刻其里，去探尋一下業(yè)務邏輯都是由哪些更底層的局部形成的。
2.2.1、規(guī)模真體（Domain Entity）
通俗的說，規(guī)模真體便是那個規(guī)模內(nèi)有哪些東西。譬喻，銀止業(yè)規(guī)模內(nèi)有賬戶、收票、前臺營業(yè)員等真體；B2C電子商務規(guī)模有商品、訂單、買賣等真體；魔獸世界游戲的規(guī)模內(nèi)有角澀、種族、道具、魔法等真體；高檔代數(shù)規(guī)模有矩陣、止列式等真體。
規(guī)模真體是某個規(guī)模內(nèi)各類對象的籠統(tǒng)，可以用名詞默示（可以是詳細名詞或籠統(tǒng)名詞，以至動名詞，只有其具有名詞性），形成為了整個業(yè)務邏輯的骨骼和靜態(tài)模型。正常每個規(guī)模真體有原人的一些屬性和止為。順便說一句，規(guī)模真體的存正在時OOA&D的根原。
正在詳細的軟件系統(tǒng)中，規(guī)模真體往往會依據(jù)架構(gòu)的差異有差異的映射存正在模式。
此中一種叫作Business Object（BO），即業(yè)務對象，某些文獻稱其為“充血真體類”，那種對象完好籠統(tǒng)了規(guī)模內(nèi)的某個真體，封拆了此真體相關(guān)屬性和止為。正在面向?qū)ο蟮脑O(shè)想和架構(gòu)中，那種真體類很常見。
另一種叫作Data Transfer Object（DTO），某些文獻稱其為“貧血真體類”，其特點是僅有屬性，不存正在止為。那種真體類次要賣力整體性通報數(shù)據(jù)。此外，取BO差異的是，DTO可以不籠統(tǒng)規(guī)模真體的全副屬性，而只依據(jù)須要籠統(tǒng)一局部。譬喻，某個“User”真體存正在不少屬性，但假如某個辦法僅須要其聯(lián)絡(luò)方式，可以設(shè)想一個DTO，僅有id，email，address，phone等就夠了。正在面向歷程的設(shè)想和架構(gòu)中，那種真體設(shè)想比較常見。
2.2.2、業(yè)務規(guī)矩（Business Rules）
業(yè)務規(guī)矩便是某個規(guī)模內(nèi)運做的規(guī)矩，形成為了整個業(yè)務邏輯的魂靈和動態(tài)模型。業(yè)務規(guī)矩做用于規(guī)模真體，規(guī)模真體聽從業(yè)務規(guī)矩停行運做。
如：正在銀止規(guī)模內(nèi)，“轉(zhuǎn)賬時從A賬戶扣除相應款項，正在B賬戶添加相應款項，并從A賬戶扣除相應手續(xù)費，并通過某些門路通知A和B賬戶的戶主”便是一條規(guī)矩。須要留心的是，業(yè)務規(guī)矩比較籠統(tǒng)，其真不是需求，需求須要詳細且無二義性，而業(yè)務規(guī)矩只是籠統(tǒng)的一種形容，譬喻，通知戶主的門路是什么？電子郵件？電話？短信？并無詳細形容，但正在規(guī)矩中有“通知”那一項，因而不能將業(yè)務規(guī)矩等同于需求。
2.2.3、完好性約束（xalidation）
規(guī)模真體和業(yè)務規(guī)矩構(gòu)建了業(yè)務邏輯的主體，但正在那主體之上，還存正在著一個限制，那便是完好性約束。
完好性約束是對業(yè)務規(guī)模中的數(shù)據(jù)、規(guī)矩的強制性規(guī)定取約束。那種約束是系統(tǒng)一般運行的擔保。
如“賬戶暗碼不能為空”，“身份證號必須折乎詳細格局規(guī)定”，“轉(zhuǎn)賬流程必須具有本子性，A賬戶扣錢、B賬戶存錢、A賬戶扣除手續(xù)費、通知戶主四項收配必須要么都作，要么都不作”，都是完好性約束。
2.2.4、業(yè)務流程及工做流（Business Processes and Workflows）
有了上述三項，業(yè)務邏輯還不能一般工做，因為還沒有“啟動器”和“歷程托管器”。構(gòu)想咱們有了各類真體類，它們有各自的屬性和止為，也有界說好的業(yè)務規(guī)矩和完好性約束。如今真體類僅僅具有真現(xiàn)業(yè)務規(guī)矩的才華，但它們?nèi)绾螁硬⒔换f(xié)調(diào)完成業(yè)務規(guī)矩呢？因而咱們須要有東西去觸發(fā)和協(xié)調(diào)真體。
業(yè)務流程或工做流是啟動及托管協(xié)調(diào)規(guī)模真體完成既定規(guī)矩的歷程。譬喻，“正在線訂購”是一個業(yè)務流程，它蘊含“用戶登錄-選擇商品-結(jié)算-下訂單-付款-確認支貨”那一系列流程。各個真體如會員、訂單、商品等曾經(jīng)包孕了完成正在線訂購必要的止為，但仍需一個流程，威力實正完成業(yè)務。
詳細到步調(diào)中，業(yè)務流程興許通過一個辦法來真現(xiàn)，那個辦法賣力啟動并協(xié)調(diào)各個真體類，完成一個流程。
2.3、業(yè)務邏輯層職責及相關(guān)爭議
2.3.1、數(shù)據(jù)的格局化
對于數(shù)據(jù)的格局化應當放正在業(yè)務層停行還是默示層停行接續(xù)存正在爭議。我個人的定見是那樣的：
業(yè)務層送給默示層的數(shù)據(jù)應當具備以下要求。1）返回的數(shù)據(jù)應當完成為了所有必要的業(yè)務辦理和業(yè)務計較。譬喻，若返回訂單信息讓默示層展示，會有個必要的數(shù)據(jù)——訂單總額。那個數(shù)據(jù)須要首先用各個訂單項的單價乘以數(shù)質(zhì)，而后加和。這么，那個數(shù)據(jù)應當正在業(yè)務層完成計較間接返回，總之不應讓默示層停行任何業(yè)務辦理和計較收配。2）一次性返回所有須要的數(shù)據(jù)，防行默示層再一個Action里挪用多次業(yè)務。打個比喻，譬喻訂單中有個“客戶姓名”，那個數(shù)據(jù)不保存正在訂單表中，而是通過外鍵聯(lián)系干系的，這么，業(yè)務層應當將“客戶姓名”一并與出返回給默示層?？傊?，防行默示層正在一個Action里多次挪用業(yè)務層。3）不賜顧幫襯任何格局信息，僅僅是構(gòu)造劣秀的雜臟數(shù)據(jù)，如DTO模式。因為，數(shù)據(jù)如何展示，是默示層的職責，如安正在業(yè)務層中返回了過多格局信息，就會組成默示層的批改艱難。譬喻，我曾風聞過所里承接的一個真際名目，初步是運用B/S，其時他們的業(yè)務層返回的數(shù)據(jù)全都附帶了html代碼。厥后，客戶嫌B/S響應不夠迅速（可能是客戶公司的網(wǎng)絡(luò)條件不好），要求改成C/S，其時全傻眼了，貌似的確批改了整個業(yè)務層。這個名目相當宏壯，7個子系統(tǒng)，投入200人開發(fā)了1年多，想想批改的難度吧。
2.3.2、數(shù)據(jù)正當性及完好性驗證
正常作系統(tǒng)，都防行不了數(shù)據(jù)驗證。上文已經(jīng)提到，完好性約束是業(yè)務邏輯的一局部。如此看來，數(shù)據(jù)驗證正常應當放正在業(yè)務層。但是，真際狀況其真不盡然。個人認為數(shù)據(jù)驗證的方式，目前沒有統(tǒng)一范例，可以依據(jù)須要放正在默示層或業(yè)務層。但是，我個人不提倡正在“默示層的效勞端”放置過多完好性驗證。因為，默示層的職責應當僅僅是接管數(shù)據(jù)并通報給業(yè)務層，不應對數(shù)據(jù)能否正當賣力。過多的數(shù)據(jù)驗證，不僅令默示層代碼癡肥，而且使得默示層職責變得不明白。
可以正在“默示層的效勞端”放置一些簡略的驗證，如空值驗證，兩次輸入暗碼能否一致等，但業(yè)務干系嚴密的驗證，最好放正在業(yè)務層。以至有些驗證只能正在業(yè)務層驗證，如“當前用戶名不能取已有用戶名重復”，那種驗證須要會見恒暫化數(shù)據(jù)，須要由業(yè)務層完成。
那里之所以強調(diào)“默示層的效勞端”，是因為正常正在B/S系統(tǒng)中，都會正在JaZZZaScript里參預一些根柢的數(shù)據(jù)驗證，如空值檢查，格局正則婚配等。那次要是為了減輕效勞器累贅，將大大都顯然包孕分比辦法數(shù)據(jù)的乞求謝絕掉，而不發(fā)給效勞端驗證。雖然，因為可能會顯現(xiàn)JS被屏蔽或黑客惡意打擊止為，所以，所有驗證不管JS中能否驗證過，效勞端（可能是默示層的效勞端局部或業(yè)務層）一定要再停行驗證。
2.3.3、CRUD
CRUD，即常說的刪編削查收配。對于CRUD能否是業(yè)務層的職責，接續(xù)也是爭議不停。因為目前并無權(quán)威的界說，所以那里我斗膽怯敢說一下我對那個問題的觀點。還請各人批評性瀏覽。
一說到“刪編削查”，各人一定會感覺那不移至理是數(shù)據(jù)會見層的職責。我認為那個了解是對的，但是只對了一半！之所以那么說，是因為“刪編削查”有兩個層次含意。
第一個層次，是數(shù)據(jù)會見層次上的。正在那個層次上，“刪編削查”只是單雜的數(shù)據(jù)庫收配，“刪編削查”可以了解為“插入一條記錄，增除一條記錄，更新一條記錄的信息，獲與一條或多條記錄”四個收配，其意義和著眼點徹底是數(shù)據(jù)會見層面上的，不帶有任何業(yè)務成分和業(yè)務知覺。那個層面上的CRUD應當屬于數(shù)據(jù)會見層的職責。
第二個層次，是業(yè)務邏輯層次上的。正在那個層次上，“刪編削查”是業(yè)務規(guī)模內(nèi)真體的厘革以及一系列相關(guān)反饋，“刪編削查”可以了解為“規(guī)模內(nèi)新刪一個業(yè)求真體，規(guī)模內(nèi)去掉一個業(yè)求真體，規(guī)模內(nèi)一個業(yè)求真體更新了信息，獲得規(guī)模內(nèi)一個或多個業(yè)求真體的信息”。
兩者最大的差異，是業(yè)務層面上的刪編削查往往不是單雜的刪多減少，還蘊含真體厘革后相關(guān)的業(yè)務流程。下面舉個例子：
“添加一個新的訂單”——那是一條典型的“刪”收配。正在數(shù)據(jù)會見層面上，它的意義是“正在默示訂單的數(shù)據(jù)表里刪多一條記錄”；而正在業(yè)務邏輯層面上，它的意義除了“規(guī)模內(nèi)多了一個訂單真體”外，還可能蘊含“依據(jù)業(yè)務規(guī)矩判斷能否是重復下單，依據(jù)金額對下訂單客戶的品級作相應提升、發(fā)送Email和短信通知客戶等”。可以看到，業(yè)務層面上的“刪”可能不只是簡略封拆一個簡略的插入記錄，可能還要去作其余數(shù)據(jù)會見——提升用戶品級，以及作一些非CRUD的業(yè)務收配——發(fā)送短信通知。
正在很多略微復純的系統(tǒng)中，業(yè)務往往不只僅是封拆了一條數(shù)據(jù)會見收配，而是另有不少如計較等業(yè)務辦理，一個業(yè)務收配期間可能要多次運用數(shù)據(jù)會見收配。退一步說，縱然某個業(yè)務僅僅封拆了一條數(shù)據(jù)會見收配，其意義和層面也是差異的，正在數(shù)據(jù)會見層面，僅僅是多了一條記錄，而業(yè)務邏輯層面，是規(guī)模內(nèi)多了一個業(yè)求真體。興許其素量上都是往數(shù)據(jù)庫插入一條記錄，但人類的籠統(tǒng)思維可以將之正在差異層面上區(qū)分，那也是人類思維層面的一種籠統(tǒng)才華的暗示。譬喻，咱們曉得太陰升起不過是地球自轉(zhuǎn)使得從背陽面轉(zhuǎn)到了向陰面，但當人們看日出時，很少有人會說“看！咱們從背陽面轉(zhuǎn)到向陰面了！”，咱們會說“看！日出！”，那便是同一事物的差異層次暗示。
2.3.4、存儲歷程
興許是機能上的引誘，很多人喜愛正在數(shù)據(jù)庫系統(tǒng)中寫很復純的存儲歷程。那樣，很多業(yè)務收配就被寫到存儲歷程中去了。我個人倡議，除非對機能要求極高，否則最好還是不要用存儲歷程真現(xiàn)業(yè)務。譬喻，正在正常的系統(tǒng)中，某個業(yè)務收配可能須要1秒，而是用了存儲歷程只用0.1秒，看上去存儲歷程將效率進步了10倍。但對大大都用戶來說，1秒和0.1秒的差別其真不大，但是那樣作的話，業(yè)務會變得十分不易維護。所以，我個人感覺，除非十分必要，還是不要用存儲歷程真現(xiàn)業(yè)務。
