第一篇：企業(yè)應(yīng)用架構(gòu)模式讀書筆記
企業(yè)應(yīng)用架構(gòu)模式讀書筆記
主要說明的問題
? 企業(yè)級(jí)程序分層
? 構(gòu)建領(lǐng)域的業(yè)務(wù)分層
?
?
?
? 構(gòu)建用戶界面 將內(nèi)存模塊影謝到關(guān)系型數(shù)據(jù)表 在無狀態(tài)下處理會(huì)話狀態(tài) 分布原則
系統(tǒng)架構(gòu)：
架構(gòu)是專家級(jí)項(xiàng)目開發(fā)人員對(duì)系統(tǒng)設(shè)計(jì)的一些可以共享的理解。這種理解可以表現(xiàn)為系統(tǒng)主要部分組成部分及這些部分的之間的交互關(guān)系。
企業(yè)應(yīng)用的特點(diǎn)
1.數(shù)據(jù)持久：程序多次運(yùn)行都必須用到他們。
2.大容量存儲(chǔ)：巨大的數(shù)據(jù)量導(dǎo)致數(shù)據(jù)的管理成為系統(tǒng)的主要工作
3.多人同時(shí)訪問：要確保多人正確的訪問數(shù)據(jù)就一定存在問題。即使人數(shù)不多要確保2個(gè)人同時(shí)操作同一數(shù)據(jù)項(xiàng)也可能存在問題。（事務(wù)管理工具可以處理以上問題但對(duì)開發(fā)者不透明）
4.存在大量用戶操作界面
5.很少有單獨(dú)存在的一般與其他周邊系統(tǒng)相互集成關(guān)于性能
1.響應(yīng)時(shí)間：系統(tǒng)完成一次外部請(qǐng)求的時(shí)間。響應(yīng)性是系統(tǒng)的一個(gè)重要指標(biāo)它表明系統(tǒng)響應(yīng)請(qǐng)求的速度。如果響應(yīng)性太慢用戶難以忍受。盡管響應(yīng)時(shí)間不慢。如果在處理請(qǐng)求期間系統(tǒng)一直處于等待狀態(tài)，則系統(tǒng)的響應(yīng)時(shí)間與響應(yīng)性是相同的，然而如果在處理完成之前給出一些信息表明系統(tǒng)已經(jīng)接受到請(qǐng)求則響應(yīng)性會(huì)好些
2.等待時(shí)間：是獲取系統(tǒng)響應(yīng)的最小時(shí)間。
3.吞吐率：給定時(shí)間內(nèi)能夠處理的最大的請(qǐng)求數(shù)。對(duì)于企業(yè)應(yīng)用來說通常用每秒事務(wù)數(shù)(tps)來度量。該指標(biāo)依賴于事務(wù)的復(fù)雜的程度
4.負(fù)載：系統(tǒng)當(dāng)前負(fù)荷的表述?？梢杂卯?dāng)前有多少用戶連接來表述。負(fù)載也可以作為其他指標(biāo)的參造。
5.負(fù)載敏感：響應(yīng)時(shí)間隨負(fù)載變化的程度.(可用衰減來表述)
6.容量：最大有效負(fù)載或吞吐量的指標(biāo)。它可以是一個(gè)絕對(duì)最大值或性能衰減至低于一個(gè)可以接受的一個(gè)值之前的臨界點(diǎn)
7.可伸縮性：度量向一個(gè)系統(tǒng)中增加資源（一般理解為硬件）對(duì)系統(tǒng)資源的影響。一個(gè)可伸縮的系統(tǒng)允許在增加新的硬件后能夠提高若干性能。垂直伸縮性指的是提高單個(gè)服務(wù)器的性能。水平伸縮性指的是增加服務(wù)器的個(gè)數(shù)。在企業(yè)應(yīng)用中關(guān)注硬件的可伸縮性比關(guān)注容量和效率更重要。
系統(tǒng)分層
用分層觀點(diǎn)來考慮系統(tǒng)時(shí)可將各子系統(tǒng)按多層蛋糕的形式來組織，每層都依賴其下層之上。在這種組織上上層使用其下層定義的服務(wù)，下層對(duì)上層一務(wù)所知。寧外每一層對(duì)其上層仍長 其下層的細(xì)節(jié)。
分層的好處：
1.在無需了解其他層次的基礎(chǔ)上可以將某一層作為一個(gè)有機(jī)整體來理解。
2.可以替換某層具體實(shí)現(xiàn)。只要提供服務(wù)相同即可。
3.可以講層次的依賴性減低到最低。
4.分層有利于標(biāo)準(zhǔn)化工作
分層的缺點(diǎn)
1.層次不能封裝所有的東西有時(shí)帶來聯(lián)級(jí)修改。
2.過多的層次影響性能
3.很難決定建立那些層次及層次的職責(zé)
分層的歷史
20世紀(jì)90年以前沒有分層
20世紀(jì)90服務(wù)器|客戶端系統(tǒng)：這種系統(tǒng)2個(gè)層次客戶端包括用戶界面和其他應(yīng)用代碼。服務(wù)器端基本上為關(guān)系型數(shù)據(jù)庫。這種方式將業(yè)務(wù)邏輯寫在客戶端顯得十分笨拙不易重用。其二：將業(yè)務(wù)邏輯寫到服務(wù)器上作為存儲(chǔ)過程。但是存儲(chǔ)過程只提供有限的結(jié)構(gòu)化機(jī)制這將再次導(dǎo)致結(jié)構(gòu)笨拙。關(guān)系型數(shù)據(jù)庫重要特點(diǎn)是標(biāo)準(zhǔn)sql，允許更換不同的關(guān)系型數(shù)據(jù)庫。單存儲(chǔ)過程是各個(gè)數(shù)據(jù)庫廠商私有的不能兼容。在服務(wù)器|客戶端普及的時(shí)期出現(xiàn)面向?qū)ο蠓绞健Ｃ嫦驅(qū)ο鬄轭I(lǐng)域邏輯的問題找到答案：轉(zhuǎn)向多層結(jié)構(gòu)。在這個(gè)結(jié)構(gòu)下表現(xiàn)層表現(xiàn)為用戶界面。在領(lǐng)域?qū)颖憩F(xiàn)領(lǐng)域邏輯，在數(shù)據(jù)層存取數(shù)據(jù)。這種方式將復(fù)雜的業(yè)務(wù)邏輯獨(dú)立出來單獨(dú)放入中間層可以加以建模和組織。
三個(gè)基本層次
1.表現(xiàn)層：提供服務(wù)、顯示信息。處理用戶與軟件的交互。主要職責(zé)是向用戶顯示信息并
從用戶那里獲取信息理解解釋為領(lǐng)域?qū)踊驍?shù)據(jù)層上的動(dòng)作。
2.領(lǐng)域?qū)樱合到y(tǒng)業(yè)務(wù)邏輯。它是應(yīng)用必須做的所有領(lǐng)域工作：包括根據(jù)輸入數(shù)據(jù)或已有的數(shù)據(jù)進(jìn)行計(jì)算。對(duì)從表現(xiàn)層輸入的數(shù)據(jù)進(jìn)行數(shù)據(jù)有效的認(rèn)證以及根據(jù)從表現(xiàn)層接受的命令調(diào)度那些數(shù)據(jù)層資源。
3.數(shù)據(jù)源層：與數(shù)據(jù)庫、消息系統(tǒng)、事務(wù)管理器及其他軟件通訊。主要關(guān)注與其他系統(tǒng)的交互。這些系統(tǒng)將代表應(yīng)用完成相關(guān)的任務(wù)。對(duì)大多少企業(yè)應(yīng)用來說就是數(shù)據(jù)庫。主要永久存儲(chǔ)數(shù)據(jù)。
層次的表現(xiàn)形式：
1.領(lǐng)域?qū)訉?duì)表現(xiàn)層完全影廠。
2.表現(xiàn)層對(duì)數(shù)據(jù)源層直接操作。
表現(xiàn)層可以解釋用戶的命令通過數(shù)據(jù)源層將相關(guān)數(shù)據(jù)從數(shù)據(jù)庫中提出來讓領(lǐng)域?qū)釉谙蛴脩麸@示前作相關(guān)的處理
表現(xiàn)層可能與數(shù)據(jù)源層一樣出現(xiàn)很多接口。因?yàn)樗麄兌际强赡苁窍到y(tǒng)的外部接口它就是
【wiki】模式的背后邏輯：它將任何系統(tǒng)都視為由到外部系統(tǒng)的接口。
分層的普遍原則：領(lǐng)域?qū)踊驍?shù)據(jù)層絕對(duì)不依賴于表現(xiàn)層。也就是說在領(lǐng)域?qū)雍蛿?shù)據(jù)層代碼中部要出現(xiàn)調(diào)用表現(xiàn)層代碼。這條規(guī)則簡(jiǎn)化在相同基礎(chǔ)上替換表現(xiàn)層的代價(jià)。也使表現(xiàn)層的修改帶來的連鎖反應(yīng)盡可能的小。
如何區(qū)分領(lǐng)域邏輯: 假想向系統(tǒng)中新增一個(gè)完全不同的新層次，如果需要重復(fù)實(shí)現(xiàn)某項(xiàng)功能則說明該功能是本該在領(lǐng)域?qū)訉?shí)現(xiàn)。
領(lǐng)域邏輯的組織
組織領(lǐng)域邏輯的三種模式：事務(wù)腳本、領(lǐng)域模式、表模塊。
1.事務(wù)腳本：保存領(lǐng)域模式的最簡(jiǎn)單的方式。它從表現(xiàn)層獲取輸入、進(jìn)行校驗(yàn)證、計(jì)算處
理、將數(shù)據(jù)保存到數(shù)據(jù)庫中、以及調(diào)用其他系統(tǒng)的操作等。然后該過程將更多的數(shù)據(jù)返回給表現(xiàn)層。基本的組織方式是讓每個(gè)過程對(duì)應(yīng)用戶的可能做的一個(gè)動(dòng)作。
優(yōu)點(diǎn)：大多數(shù)人都能理解的簡(jiǎn)單過程
能夠使用行數(shù)據(jù)入口或表數(shù)據(jù)入口
很容易表述事務(wù)的邊界
缺點(diǎn)：
當(dāng)如干事務(wù)需要做相類似的操作時(shí)通常腳本里包含相同的代碼。通過這些相同的代碼可以組成公共函數(shù)可以消除次現(xiàn)象，但在很多時(shí)候消除副本或檢測(cè)副本都困難這樣使得程序結(jié)構(gòu)不清晰。
領(lǐng)域模式：在整個(gè)過程中不是由一個(gè)過程來完成某一業(yè)務(wù)邏輯，而是在過程中產(chǎn)生若干對(duì)象由每個(gè)對(duì)象都承擔(dān)一部分相關(guān)邏輯。
表模塊：它與領(lǐng)域模式類似。關(guān)鍵區(qū)別在與領(lǐng)域模式對(duì)數(shù)據(jù)表中的每條記錄有一個(gè)相應(yīng)的實(shí)例而表模式只要一個(gè)綜合實(shí)例。它是事務(wù)腳本與領(lǐng)域模式的一個(gè)中間者，它圍繞表而非直接圍繞過程組織領(lǐng)域邏輯，提供更多的結(jié)構(gòu)、而且更容易發(fā)現(xiàn)冗余代碼。它最大的優(yōu)點(diǎn)就是與軟件架構(gòu)中已有的部分銜接。
第二篇：企業(yè)移動(dòng)應(yīng)用安全超市技術(shù)架構(gòu)研究
企業(yè)移動(dòng)應(yīng)用安全超市技術(shù)架構(gòu)研究
王嘉延，楊杰，戴浩良
（中國南方電網(wǎng)廣州供電局有限公司，廣州510620）
摘要：
針對(duì)電力企業(yè)移動(dòng)化建設(shè)過程中，如何實(shí)現(xiàn)大量的企業(yè)移動(dòng)應(yīng)用進(jìn)行全生命周期的管理問題，提出企業(yè)移動(dòng)應(yīng)用安全超市的企業(yè)移動(dòng)應(yīng)用管理架構(gòu)體系，并結(jié)合實(shí)名制終端設(shè)備和用戶管理技術(shù)、基于SSL VPN 的數(shù)據(jù)安全通道技術(shù)和終端數(shù)據(jù)安全技術(shù)，提出一套完全符合電力行業(yè)移動(dòng)應(yīng)用管理架構(gòu)和技術(shù)方案，有效解決電力企業(yè)移動(dòng)應(yīng)用全生命周期管理的問題。關(guān)鍵詞：
企業(yè)移動(dòng)化；應(yīng)用電子市場(chǎng)；企移動(dòng)應(yīng)用超市；信息安全；云計(jì)算
0 引言
以智能手機(jī)、平板電腦的廣泛應(yīng)用為標(biāo)志的移動(dòng)互聯(lián)網(wǎng)時(shí)代來臨，已經(jīng)對(duì)包括電力行業(yè)在內(nèi)的企業(yè)信息化進(jìn)程帶來了深遠(yuǎn)的影響。已經(jīng)習(xí)慣于使用智能移動(dòng)終端來進(jìn)行交流、溝通和信息獲取的企業(yè)員工，提出了越來越多的企業(yè)業(yè)務(wù)移動(dòng)化的要求。然而，企業(yè)移動(dòng)化不是簡(jiǎn)單地將企業(yè)應(yīng)用遷移或移植到智能移動(dòng)終端上就可以了，由于智能移動(dòng)應(yīng)用具有多平臺(tái)、開放性、小型化、碎片化、個(gè)人化和隨時(shí)更新下載等新的特點(diǎn)，對(duì)企業(yè)信息化管理，尤其是關(guān)系到國家能源安全的電力行業(yè)帶來了全新的挑戰(zhàn)。
企業(yè)移動(dòng)化對(duì)電力企業(yè)信息化建設(shè)和管理帶來了全新的挑戰(zhàn)：
（1）包括iOS、Android、Windows Phone 在內(nèi)的智能終端平臺(tái)操作的多樣性差異和海量的移動(dòng)應(yīng)用，為企業(yè)移動(dòng)化管理帶來巨大的挑戰(zhàn)；
（2）用戶已經(jīng)習(xí)慣通過第三方公共應(yīng)用市場(chǎng)，大量下載和更新移動(dòng)應(yīng)用，如何對(duì)企業(yè)移動(dòng)應(yīng)用進(jìn)行統(tǒng)一安全發(fā)布管理，也是電力企業(yè)移動(dòng)化建設(shè)面臨的新問題；（3）移動(dòng)智能終端應(yīng)用接入和使用的身份認(rèn)證問題；
（4）由此帶來的移動(dòng)智能終端應(yīng)用企業(yè)數(shù)據(jù)安全訪問問題。針對(duì)以上在企業(yè)移動(dòng)化中面臨的突出問題，結(jié)合電力企業(yè)信息化安全管理規(guī)范，南方電網(wǎng)廣州電力局的王嘉延、楊杰和戴浩良三人共同創(chuàng)新規(guī)劃和設(shè)計(jì)了面向未來電力企業(yè)移動(dòng)應(yīng)用管理的“企業(yè)移動(dòng)應(yīng)用安全超市”的企業(yè)移動(dòng)化應(yīng)用管理平臺(tái)框架，有效解決了上面企業(yè)移動(dòng)應(yīng)用管理的四個(gè)問題。企業(yè)移動(dòng)應(yīng)用安全超市架構(gòu) 目前，針對(duì)智能移動(dòng)終端的移動(dòng)應(yīng)用分發(fā)，主要依賴于由蘋果公司首創(chuàng)的移動(dòng)應(yīng)用電子市場(chǎng)（App Store）模式。但是，包括蘋果公司在內(nèi)的App Store，所分發(fā)和管理的移動(dòng)應(yīng)用，由于是對(duì)平臺(tái)內(nèi)所有終端用戶都是開放的，更適合通用的移動(dòng)應(yīng)用的分發(fā)和管理。尤其是Android平臺(tái)，由于沒有對(duì)移動(dòng)應(yīng)用的來源做嚴(yán)格的審核和驗(yàn)證，大量非原廠的第三方App Store 已經(jīng)占據(jù)了Android平臺(tái)的移動(dòng)應(yīng)用分發(fā)和管理的主要份額，例如有三星、華為這些手機(jī)廠商，也有91 手機(jī)助手、運(yùn)營商背景的各種電子市場(chǎng)，由此帶來移動(dòng)應(yīng)用管理存在巨大的安全風(fēng)險(xiǎn)和隱患。
因此，對(duì)于面向企業(yè)移動(dòng)化的企業(yè)移動(dòng)應(yīng)用管理，尤其是企業(yè)內(nèi)部使用的移動(dòng)應(yīng)用，這些由第三方管理 的App Store 顯然無法滿足企業(yè)移動(dòng)應(yīng)用管理的要求，尤其是對(duì)信息安全要求比較高的電力行業(yè)企業(yè)，更有迫切的要求能夠由一套安全和企業(yè)自主管理的AppStore，用于對(duì)企業(yè)的移動(dòng)應(yīng)用進(jìn)行統(tǒng)一管理，在保證安全的前提下，實(shí)現(xiàn)企業(yè)應(yīng)用移動(dòng)化提升企業(yè)信息化能力的目標(biāo)?；谝陨峡紤]，筆者就建設(shè)符合電力企業(yè)移動(dòng)化管理要求的“移動(dòng)應(yīng)用安全超市”的相關(guān)技術(shù)和架構(gòu)進(jìn)行了研究，并以這項(xiàng)研究為基礎(chǔ)，最終研發(fā)出“移動(dòng)接入辦公平臺(tái)系統(tǒng)”產(chǎn)品，完全實(shí)現(xiàn)了移動(dòng)應(yīng)用安全超市的技術(shù)目標(biāo)。（1）建立企業(yè)移動(dòng)應(yīng)用超市系統(tǒng)架構(gòu)
在目前企業(yè)的主流的智能移動(dòng)終端系統(tǒng)平臺(tái)中，以蘋果公司為代表的系統(tǒng)平臺(tái)廠商，專門為需要自主主建設(shè)企業(yè)應(yīng)用超市的企業(yè)，提供了一套完整的企業(yè)開發(fā)者計(jì)劃（“Apple Developer Enterprise Program”），允許申請(qǐng)加入該計(jì)劃的企業(yè)，除了在其提供的面向大眾的App Store 之外，建設(shè)符合自身移動(dòng)應(yīng)用管理要求的企業(yè)移動(dòng)應(yīng)用電子市場(chǎng)。對(duì)于包括Android 這樣的系統(tǒng)平臺(tái)，則由于其本身就沒有對(duì)第三方移動(dòng)應(yīng)用的發(fā)布做太多限制，允許企業(yè)建設(shè)自主管理的企業(yè)應(yīng)用電子市場(chǎng)來自主進(jìn)行移動(dòng)應(yīng)用的發(fā)布管理。
下圖是以蘋果公司的“Apple Developer EnterpriseProgram”所提供的技術(shù)規(guī)范基礎(chǔ)上，結(jié)合電力行業(yè)企業(yè)移動(dòng)化管理規(guī)范和特征，梳理出完全能夠滿足電力企業(yè)移動(dòng)應(yīng)用管理要求的企業(yè)移動(dòng)應(yīng)用超市體系框架圖如圖1 所示。
企業(yè)移動(dòng)應(yīng)用超市體系框架，主要包括兩大部分組成：“企業(yè)應(yīng)用超市客戶端”和“企業(yè)應(yīng)用超市云平臺(tái)”，構(gòu)建成“云＋端”的企業(yè)移動(dòng)應(yīng)用管理體系。（2）企業(yè)應(yīng)用超市客戶端（以下簡(jiǎn)稱平臺(tái)App）功能和體系架構(gòu)平臺(tái)App 是安裝在企業(yè)用戶的智能終端上，作為企業(yè)移動(dòng)應(yīng)用發(fā)布的門戶和窗口。平臺(tái)App 作為企業(yè)移動(dòng)應(yīng)用超市的用戶客戶端，不僅支持Android、iOS、WP 等不同操作系統(tǒng)平臺(tái)，也同時(shí)能夠支持多品牌廠商、多種分辨率的智能手機(jī)和智能平板電腦。圖2 為平臺(tái)App 軟件架構(gòu)設(shè)計(jì)圖。
為了保證平臺(tái)App 具備的靈活性和可擴(kuò)展能力，客戶端軟件劃分為四層，分別是“UI 交互層”、“UI 適配層”、“業(yè)務(wù)邏輯層”和“系統(tǒng)能力適配層”，以降低層次系統(tǒng)的耦合性。例如：通?？蛻舳俗兓容^多的部分集中在UI 交互層（調(diào)整界面布局、風(fēng)格定制、更換主題等），這樣的劃分可以將變動(dòng)限制在一定范圍內(nèi)，減少變動(dòng)引起的工作量，提高軟件的可維護(hù)性。（3）企業(yè)應(yīng)用超市云平臺(tái)功能和體系架構(gòu)
企業(yè)應(yīng)用管理云平臺(tái)，是企業(yè)移動(dòng)應(yīng)用管理后臺(tái)，為企業(yè)提供移動(dòng)應(yīng)用全生命周期的管理。企業(yè)應(yīng)用超市云平臺(tái)由“企業(yè)移動(dòng)應(yīng)用超市”、“企業(yè)移動(dòng)應(yīng)用超市控制臺(tái)”、“企業(yè)移動(dòng)應(yīng)用超市門戶網(wǎng)站”和“企業(yè)移動(dòng)接入管理”四個(gè)模塊組成。
●“企業(yè)移動(dòng)應(yīng)用超市”作為企業(yè)移動(dòng)應(yīng)用的管理核心，提供了包括“應(yīng)用類別管理”、“應(yīng)用來源管理”、“應(yīng)用中心”、“應(yīng)用分發(fā)管理”和“應(yīng)用超市客戶端”管理的職責(zé)，能夠?qū)崿F(xiàn)對(duì)應(yīng)用簽名認(rèn)證用于驗(yàn)證應(yīng)用的合法來源與完整性，確保應(yīng)用安全，并與企業(yè)應(yīng)用超市App 客戶端，實(shí)現(xiàn)了企業(yè)應(yīng)用管理全生命周期管理?！瘛捌髽I(yè)移動(dòng)應(yīng)用超市控制臺(tái)”是提供給企業(yè)移動(dòng)移動(dòng)應(yīng)用管理人員對(duì)企業(yè)移動(dòng)應(yīng)用進(jìn)行管理的門戶平臺(tái)。
●“企業(yè)移動(dòng)應(yīng)用超市門戶網(wǎng)站”則是直接面向企業(yè)內(nèi)部員工和企業(yè)合作伙伴，了解企業(yè)移動(dòng)應(yīng)用發(fā)布和更新情況，下載更新平臺(tái)App，以獲得最新的平臺(tái)App 版本更新。
●“企業(yè)移動(dòng)接入管理”是整個(gè)企業(yè)移動(dòng)應(yīng)用超市的基礎(chǔ)支撐模塊，提供對(duì)智能終端設(shè)備、企業(yè)移動(dòng)應(yīng)用超市用戶進(jìn)行實(shí)名身份安全認(rèn)證和數(shù)據(jù)安全傳輸?shù)哪芰?，保證只有獲得企業(yè)授權(quán)的合法的用戶才能對(duì)企業(yè)進(jìn)行安全訪問。（3）企業(yè)移動(dòng)應(yīng)用超市平臺(tái)邏輯架構(gòu) 企業(yè)移動(dòng)應(yīng)用超市作為面向企業(yè)移動(dòng)互聯(lián)網(wǎng)信息化的創(chuàng)新型應(yīng)用平臺(tái)系統(tǒng)，要求系統(tǒng)自身應(yīng)具備移動(dòng)互聯(lián)網(wǎng)平臺(tái)特性。由本文作者共同研究和設(shè)計(jì)的面向電力行業(yè)“企業(yè)移動(dòng)應(yīng)用安全超市”，就是按照云計(jì)算架構(gòu)進(jìn)行規(guī)劃和設(shè)計(jì)。如圖3 所示。
南方電網(wǎng)廣州供電局已經(jīng)在內(nèi)部實(shí)施基于虛擬化技術(shù)的私有云計(jì)算基礎(chǔ)架構(gòu)，可以直接對(duì)內(nèi)提供IaaS模式的云平臺(tái)服務(wù)?！捌髽I(yè)移動(dòng)應(yīng)用安全超市”在設(shè)計(jì)的時(shí)候，就已經(jīng)考慮能夠直接利用廣州供電局基于IaaS 的基礎(chǔ)網(wǎng)絡(luò)運(yùn)算能力，直接運(yùn)行在廣州供電局的內(nèi)部私有云平臺(tái)上，通過私有云平臺(tái)提供的強(qiáng)大的系統(tǒng)伸縮性和數(shù)據(jù)安全備份能力，保證“企業(yè)移動(dòng)應(yīng)用安全超市”持續(xù)穩(wěn)定運(yùn)行。
“企業(yè)移動(dòng)應(yīng)用安全超市云平臺(tái)”，則是按照PaaS云計(jì)算架構(gòu)進(jìn)行規(guī)劃和設(shè)計(jì)的。通過對(duì)企業(yè)移動(dòng)應(yīng)用超市的業(yè)務(wù)流程進(jìn)行模塊化分離，能夠?qū)ν饪缙脚_(tái)的企業(yè)移動(dòng)應(yīng)用管理能力。而“企業(yè)應(yīng)用超市客戶端”則不僅僅只是設(shè)計(jì)作為執(zhí)行移動(dòng)應(yīng)用分發(fā)單一功能的客戶端App 軟件，而是在設(shè)計(jì)的時(shí)候，也充分考慮未來企業(yè)云計(jì)算應(yīng)用前進(jìn)，將客戶端同時(shí)設(shè)計(jì)作為SaaS 化的企業(yè)移動(dòng)應(yīng)用訪問門戶，例如企業(yè)通訊錄，就是直接由平臺(tái)客戶端軟件直接提供的服務(wù)化的移動(dòng)應(yīng)用功能，不需要終端用戶另外安裝客戶端。除此之外，平臺(tái)客戶端內(nèi)置基于HTML5 應(yīng)用支撐框架，作為未來基于SaaS 的企業(yè)移動(dòng)應(yīng)用開發(fā)基礎(chǔ)，為未來企業(yè)移動(dòng)化應(yīng)用提供無限擴(kuò)展能力。
（3）企業(yè)移動(dòng)應(yīng)用安全超市關(guān)鍵技術(shù)
除了以上所述的系統(tǒng)框架之外，下面的幾個(gè)關(guān)鍵技術(shù)問題，也是此次研究重點(diǎn)研究問題，以保證已經(jīng)確定的系統(tǒng)框架，在電力行業(yè)具備實(shí)用性： 問題1：關(guān)于設(shè)備和用戶認(rèn)證的問題。
身份認(rèn)證是企業(yè)移動(dòng)應(yīng)用超市管理的關(guān)鍵的支撐技術(shù)。針對(duì)移動(dòng)應(yīng)用的復(fù)雜性，本文所規(guī)劃設(shè)計(jì)的“企業(yè)移動(dòng)應(yīng)用安全超市”按照目前比較成熟MDM 安全管理技術(shù)，設(shè)計(jì)了一套結(jié)合智能終端設(shè)備自動(dòng)設(shè)備、登錄用戶在線認(rèn)證和移動(dòng)電話在線認(rèn)證等手段，實(shí)現(xiàn)基于終端設(shè)備及用戶的實(shí)名認(rèn)證機(jī)制，保證只有合法的和安全的設(shè)備和用戶才能使用和訪問企業(yè)移動(dòng)應(yīng)用超市。
問題2：數(shù)據(jù)安全共享問題
由于電力行業(yè)對(duì)數(shù)據(jù)安全性要求比較高，尤其是企業(yè)移動(dòng)應(yīng)用會(huì)需要直接訪問電力企業(yè)的內(nèi)部系統(tǒng)數(shù)據(jù)。未來保證數(shù)據(jù)傳輸?shù)陌踩??！捌髽I(yè)移動(dòng)應(yīng)用安全超市”內(nèi)建基于SSL VPN 的數(shù)據(jù)安全通道加密技術(shù)，所有移動(dòng)應(yīng)用都只能通過該安全通道，對(duì)企業(yè)進(jìn)行系統(tǒng)訪問和數(shù)據(jù)交換，保證數(shù)據(jù)傳輸和共享的安全。
問題3：移動(dòng)終端數(shù)據(jù)安全保密的問題。針對(duì)移動(dòng)終端可能存在遺失的情況，“企業(yè)移動(dòng)應(yīng)用安全超市”的平臺(tái)客戶端內(nèi)建動(dòng)態(tài)數(shù)據(jù)安全區(qū)，保證數(shù)據(jù)在移動(dòng)端的安全性。并結(jié)合MDM 設(shè)備安全管理技術(shù)，實(shí)現(xiàn)遠(yuǎn)程安全擦出數(shù)據(jù)、鎖定手機(jī)的機(jī)制，保證數(shù)據(jù)安全使用和存儲(chǔ)。2 結(jié)語
經(jīng)過研究，確定以安全云計(jì)算基礎(chǔ)架構(gòu)參照，構(gòu)建符合電力企業(yè)移動(dòng)信息化建設(shè)要求的“企業(yè)移動(dòng)應(yīng)用超市”，作為企業(yè)移動(dòng)應(yīng)用承擔(dān)發(fā)布、更新和升級(jí)的管理平臺(tái)，實(shí)現(xiàn)對(duì)企業(yè)移動(dòng)應(yīng)用全生命周期管理。結(jié)合實(shí)名制終端設(shè)備和用戶管理技術(shù)、基于SSL VPN 的數(shù)據(jù)安全通道技術(shù)和終端數(shù)據(jù)安全技術(shù)，保證“企業(yè)移動(dòng)應(yīng)用超市”完全符合電力企業(yè)信息安全合規(guī)管理要求，在企業(yè)移動(dòng)信息化體系中發(fā)揮持久的效能。
第三篇：企業(yè)法律風(fēng)險(xiǎn)管理的基礎(chǔ)、架構(gòu)與模式
企業(yè)法律風(fēng)險(xiǎn)管理的基礎(chǔ)、架構(gòu)與模式
法律風(fēng)險(xiǎn)管理是企業(yè)風(fēng)險(xiǎn)管理的一部分，風(fēng)險(xiǎn)管理又是企業(yè)管理的一部分。這就是說，公司法務(wù)進(jìn)行法律風(fēng)險(xiǎn)管理，要取得成效，必須融入到企業(yè)的經(jīng)營管理活動(dòng)中，而不能“就法律講法律”。
要實(shí)現(xiàn)融入，須借助于企業(yè)的管理機(jī)制與管理要素，如企業(yè)政策、規(guī)章制度、部門結(jié)構(gòu)、工作流程，績(jī)效考核等。通過這些要素的有序結(jié)合，可形成一套普遍適用的企業(yè)法律風(fēng)險(xiǎn)管理機(jī)制。
一、法律風(fēng)險(xiǎn)管理意識(shí)
企業(yè)經(jīng)營管理的每一環(huán)節(jié)，均可能產(chǎn)生法律風(fēng)險(xiǎn)，要對(duì)其進(jìn)行有效管理，須先持有正確的企業(yè)法律風(fēng)險(xiǎn)管理意識(shí)。
法律風(fēng)險(xiǎn)管理意識(shí)，指企業(yè)法務(wù)人員、業(yè)務(wù)人員和管理者對(duì)企業(yè)法律風(fēng)險(xiǎn)的存在、后果，以及如何應(yīng)對(duì)等方面是否有足夠的認(rèn)知。
首先，企業(yè)決策層對(duì)法律風(fēng)險(xiǎn)的存在、后果，應(yīng)對(duì)措施是否有足夠的認(rèn)識(shí)。能否將這種認(rèn)識(shí)轉(zhuǎn)化為對(duì)本企業(yè)的法律風(fēng)險(xiǎn)的管理理念和管理承諾，對(duì)于一個(gè)企業(yè)的整體法律風(fēng)險(xiǎn)管理工作來說，顯得至關(guān)重要。
其次，除了最高管理者的法律風(fēng)險(xiǎn)管理意識(shí)外，具體的執(zhí)行和實(shí)施部門人員的法律風(fēng)險(xiǎn)管理意識(shí)也很關(guān)鍵。作為專業(yè)的風(fēng)險(xiǎn)管理者，法務(wù)部及其工作人員，上至法務(wù)總監(jiān)，下至法務(wù)專員以及法務(wù)部聘請(qǐng)的外部律師，都應(yīng)對(duì)本企業(yè)的法律風(fēng)險(xiǎn)有著清楚的認(rèn)識(shí)和理解。法務(wù)部的法律風(fēng)險(xiǎn)管理意識(shí)尤應(yīng)清晰、敏銳。在必 要時(shí)，法務(wù)人員還須對(duì)其他業(yè)務(wù)部門人員進(jìn)行專門的法律風(fēng)險(xiǎn)意識(shí)的培訓(xùn)，以期更好地執(zhí)行和實(shí)施法律風(fēng)險(xiǎn)管理工作。
最后，企業(yè)法律風(fēng)險(xiǎn)可能來自于企業(yè)經(jīng)營管理的任何環(huán)節(jié)，因此，全面的企業(yè)法律風(fēng)險(xiǎn)管理工作還應(yīng)得到企業(yè)所有員工的參與和支持，他們的法律風(fēng)險(xiǎn)意識(shí)對(duì)完善的企業(yè)法律風(fēng)險(xiǎn)管理工作也必不可少。
那么，如何形成企業(yè)法律風(fēng)險(xiǎn)管理意識(shí)呢？在不同企業(yè)，路徑大不相同。以下步驟可表示其形成的一般路徑。第一步，法務(wù)人員就本企業(yè)法律風(fēng)險(xiǎn)管理的現(xiàn)狀提出問題，挖掘具體需求，然后管理層對(duì)此進(jìn)行正式的認(rèn)同，并承諾上升為本企業(yè)全面風(fēng)險(xiǎn)管理的一部分。第二步，全體員工逐步認(rèn)識(shí)到法律風(fēng)險(xiǎn)管理在本企業(yè)實(shí)施的必要性和重要性，并積極參與進(jìn)來。第三步，法務(wù)部或其聘請(qǐng)的外部咨詢機(jī)構(gòu)制定具體的法律風(fēng)險(xiǎn)管理實(shí)施計(jì)劃。最后，通過持續(xù)地實(shí)施法律風(fēng)險(xiǎn)管理計(jì)劃，最終可望形成企業(yè)的法律風(fēng)險(xiǎn)管理意識(shí)。
要說明的是，管理層的風(fēng)險(xiǎn)管理承諾意識(shí)、法務(wù)部的風(fēng)險(xiǎn)管理實(shí)施意識(shí)、全體員工的風(fēng)險(xiǎn)管理責(zé)任承擔(dān)意識(shí)，都離不開企業(yè)整體的法律風(fēng)險(xiǎn)意識(shí)文化的培養(yǎng)和塑造。當(dāng)企業(yè)各層在法律風(fēng)險(xiǎn)管理意識(shí)上達(dá)成共識(shí)，且能主動(dòng)的履行防范法律風(fēng)險(xiǎn)的職責(zé)時(shí)，可以說，該企業(yè)才算形成企業(yè)法律風(fēng)險(xiǎn)管理文化。法律風(fēng)險(xiǎn)管理文化，其實(shí)質(zhì)是統(tǒng)一的、深層次的法律風(fēng)險(xiǎn)管理意識(shí)。樹立穩(wěn)定且有效的法律風(fēng)險(xiǎn)管理文化，可謂法律風(fēng)險(xiǎn)管理的最高目標(biāo)。
二、法律風(fēng)險(xiǎn)管理制度
在企業(yè)具備法律風(fēng)險(xiǎn)管理意識(shí)的同時(shí)，應(yīng)制定相應(yīng)的企業(yè)內(nèi)部制度來落實(shí)。法律風(fēng)險(xiǎn)管理制度是法律風(fēng)險(xiǎn)管理意識(shí)轉(zhuǎn)化為法律風(fēng)險(xiǎn)管理行為的橋梁。企業(yè)法律風(fēng)險(xiǎn)管理制度是企業(yè)規(guī)章制度的一部分，是對(duì)企業(yè)法律風(fēng)險(xiǎn)管理進(jìn)行書面化和常規(guī)化。完善的法律風(fēng)險(xiǎn)管理制度的建立，是企業(yè)法律風(fēng)險(xiǎn)管理的關(guān)鍵要素之一。
一方面，法律風(fēng)險(xiǎn)管理制度必須體現(xiàn)企業(yè)法律風(fēng)險(xiǎn)管理的意識(shí)和理念，并且能與企業(yè)經(jīng)營管理制度融合在一起，激勵(lì)和約束企業(yè)的經(jīng)營管理行為。
另一方面法律風(fēng)險(xiǎn)管理制度又必須自成體系，至少要包含以下三個(gè)層面： 第一，法律風(fēng)險(xiǎn)管理制度應(yīng)滿足企業(yè)規(guī)章制度的一般特點(diǎn)，即可執(zhí)行、可操作； 第二，法律風(fēng)險(xiǎn)管理制度應(yīng)在現(xiàn)行法律框架下，集中考慮法律風(fēng)險(xiǎn)處理的特殊要求，重點(diǎn)規(guī)定基于法律的管理行為。如在制定法律風(fēng)險(xiǎn)識(shí)別相關(guān)制度時(shí)，就要考慮是基于法律環(huán)境的變化，是我方或?qū)Ψ竭`規(guī)，還是對(duì)方違約或侵權(quán)，抑或?qū)Ψ讲划?dāng)行為或我方怠于行使權(quán)利等各種法律上的情況；
第三，需要強(qiáng)調(diào)的是，法律風(fēng)險(xiǎn)管理制度本身應(yīng)有單獨(dú)的獎(jiǎng)懲規(guī)定。這種獎(jiǎng)懲不僅是制度中涉及的獎(jiǎng)懲行為，而且還應(yīng)對(duì)是否積極或消極地實(shí)施法律風(fēng)險(xiǎn)管理的行為進(jìn)行獎(jiǎng)懲。
企業(yè)法律風(fēng)險(xiǎn)管理制度要體現(xiàn)出企業(yè)各部門、各人員的風(fēng)險(xiǎn)管理職責(zé)，并配備相應(yīng)的考核規(guī)則和獎(jiǎng)罰制度。
三、法律風(fēng)險(xiǎn)管理人員
企業(yè)風(fēng)險(xiǎn)管理永遠(yuǎn)是通過組織中的人、通過他們的言行來完成的。人制定了主體的使命、戰(zhàn)略和目標(biāo)，并使企業(yè)風(fēng)險(xiǎn)管理機(jī)制得以落實(shí)。企業(yè)法律風(fēng)險(xiǎn)管理意識(shí)的塑造和制度的貫徹實(shí)施，與企業(yè)員工的素質(zhì)密不可分。法律風(fēng)險(xiǎn)方面的人力資源工作對(duì)于企業(yè)進(jìn)行法律風(fēng)險(xiǎn)管理來說，同樣重要。鑒于企業(yè)法律風(fēng)險(xiǎn)管理意識(shí)的發(fā)起和企業(yè)法律風(fēng)險(xiǎn)管理制度的制定實(shí)施是以法務(wù)部人員為主，那么，在配置企業(yè)法律風(fēng)險(xiǎn)管理資源時(shí)，本企業(yè)是否存在從事法律風(fēng)險(xiǎn)管理的專門人員，以及這些人員是否具備相應(yīng)素質(zhì)和能力，對(duì)該企業(yè)法律風(fēng)險(xiǎn)管理能否達(dá)預(yù)期目標(biāo)至關(guān)重要。
在配置本企業(yè)法律風(fēng)險(xiǎn)管理人員組成時(shí)，尤其要注意兩種人。一是本企業(yè)法律事務(wù)的負(fù)責(zé)人，即法務(wù)總監(jiān)。他（她）們作為企業(yè)法律風(fēng)險(xiǎn)管理事務(wù)的負(fù)責(zé)人，其法律風(fēng)險(xiǎn)管理水平和理念，對(duì)于一個(gè)企業(yè)來說，起著領(lǐng)航的作用。法務(wù)總監(jiān)的配置是企業(yè)法律風(fēng)險(xiǎn)管理人力資源工作的核心。必須要求法務(wù)總監(jiān)不僅懂法律，而且要具備管理經(jīng)驗(yàn)；不僅能與業(yè)務(wù)部門、職能部門打交道，更重要會(huì)與企業(yè)決策層打交道。法務(wù)總監(jiān)在企業(yè)老總的法律風(fēng)險(xiǎn)意識(shí)不強(qiáng)時(shí)，必須能說服和引導(dǎo)領(lǐng)導(dǎo)主動(dòng)支持在企業(yè)中實(shí)施法律風(fēng)險(xiǎn)管理。
二是企業(yè)聘請(qǐng)的外部專業(yè)咨詢者，如執(zhí)業(yè)律師、風(fēng)險(xiǎn)評(píng)估咨詢師、學(xué)者專家等。這些人員的配置也是必須的，他們應(yīng)與企業(yè)內(nèi)部法律事務(wù)部門人員有個(gè)合理的分工。當(dāng)然，在采納外部專家意見時(shí)，也要考慮其本身的局限性。需要說明的是，在配置企業(yè)法律風(fēng)險(xiǎn)管理人力資源時(shí)，不管是內(nèi)部法律事務(wù)部人員，還是外部法律專家，都必須明確該人員在企業(yè)法律風(fēng)險(xiǎn)管理體系中的職責(zé)。
現(xiàn)代企業(yè)的法律風(fēng)險(xiǎn)管理是個(gè)系統(tǒng)工作，僅靠法務(wù)總監(jiān)或外部專家咨詢者是無法單獨(dú)完成的，還必須有其他各人員的配合。把這些人員集合起來，就組成了專門處理法律風(fēng)險(xiǎn)的部門，可稱為法律風(fēng)險(xiǎn)管理部或法律風(fēng)險(xiǎn)合規(guī)部。
在多數(shù)企業(yè)當(dāng)中，這個(gè)部門的職責(zé)一般包含在法務(wù)部或合規(guī)部當(dāng)中。專門成立一個(gè)法律風(fēng)險(xiǎn)管理部的較少。在人員安排上，除有一個(gè)具有管理經(jīng)驗(yàn)和風(fēng)險(xiǎn)管 理理念的負(fù)責(zé)人，即法務(wù)總監(jiān)以外，最好能配上兩個(gè)法務(wù)經(jīng)理。一個(gè)懂法律，也稍懂財(cái)務(wù)；另一個(gè)懂法律，也稍懂本企業(yè)技術(shù)。
四、法律風(fēng)險(xiǎn)管理流程
各企業(yè)根據(jù)自身管理基礎(chǔ)和資源投入等情況，所采取的法律風(fēng)險(xiǎn)管理措施肯定不盡相同。為規(guī)范企業(yè)風(fēng)險(xiǎn)管理行為，推行企業(yè)風(fēng)險(xiǎn)管理最佳實(shí)踐，國際和國內(nèi)的相關(guān)機(jī)構(gòu)都各自推出了多種風(fēng)險(xiǎn)管理標(biāo)準(zhǔn)或?qū)嵤┲改稀?/p>
知名的有風(fēng)險(xiǎn)管理標(biāo)準(zhǔn)有：
COSO
《企業(yè)風(fēng)險(xiǎn)管理——整合框架》 澳大利亞-新西蘭風(fēng)險(xiǎn)管理標(biāo)準(zhǔn)
AS/NZS4360 國際標(biāo)準(zhǔn)化組織ISO 31000《風(fēng)險(xiǎn)管理原則與指南》 ISO/IEC 31010：2009《風(fēng)險(xiǎn)管理技術(shù)》
中國國家標(biāo)準(zhǔn)化管理委員會(huì)
GB/T 24353-2009《風(fēng)險(xiǎn)管理 原則與實(shí)施指南》 中國國家標(biāo)準(zhǔn)化管理委員會(huì)
GB/T 27914-2011《企業(yè)法律風(fēng)險(xiǎn)管理指南》等。
通過歸納、借鑒以上所述的國內(nèi)外企業(yè)風(fēng)險(xiǎn)管理標(biāo)準(zhǔn)，可總結(jié)企業(yè)法律風(fēng)險(xiǎn)管理的一般流程。
1.確定本企業(yè)法律風(fēng)險(xiǎn)準(zhǔn)則。風(fēng)險(xiǎn)準(zhǔn)則是衡量法律風(fēng)險(xiǎn)重要程度的尺子，體現(xiàn)了企 業(yè)對(duì)法律風(fēng)險(xiǎn)管理的價(jià)值觀、偏好與承受度。在有的風(fēng)險(xiǎn)管理標(biāo)準(zhǔn)中，風(fēng)險(xiǎn)準(zhǔn)則和另一個(gè)概念“風(fēng)險(xiǎn)容量”基本相同。風(fēng)險(xiǎn)容量是一個(gè)企業(yè)在追求價(jià)值的過程中所愿意承擔(dān)的廣泛意義上的風(fēng)險(xiǎn)的數(shù)量。
2.收集本企業(yè)法律風(fēng)險(xiǎn)環(huán)境信息。風(fēng)險(xiǎn)環(huán)境信息是后續(xù)法律風(fēng)險(xiǎn)管理活動(dòng)得以順利實(shí)施的基礎(chǔ)，包括外部和內(nèi)部風(fēng)險(xiǎn)環(huán)境信息。環(huán)境信息收集目的在于明確 法律風(fēng)險(xiǎn)管理目標(biāo)，并設(shè)定法律風(fēng)險(xiǎn)管理的范圍和有關(guān)風(fēng)險(xiǎn)準(zhǔn)則。信息的收集應(yīng)根據(jù)企業(yè)法律風(fēng)險(xiǎn)狀況變化及企業(yè)的管理需要進(jìn)行調(diào)整和補(bǔ)充。
3.進(jìn)行企業(yè)法律風(fēng)險(xiǎn)評(píng)估。風(fēng)險(xiǎn)評(píng)估包括風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)分析和風(fēng)險(xiǎn)評(píng)價(jià)三個(gè)環(huán)節(jié)。在識(shí)別環(huán)節(jié)，形成本企業(yè)法律風(fēng)險(xiǎn)清單；在分析環(huán)節(jié)，采用定性與定量方法，建立模型，參照專家意見，對(duì)企業(yè)法律風(fēng)險(xiǎn)事件發(fā)生的可能性與影響程度等方面進(jìn)行具體分析；在評(píng)價(jià)環(huán)節(jié)，將風(fēng)險(xiǎn)分析的結(jié)果與法律風(fēng)險(xiǎn)準(zhǔn)則相比較，進(jìn)行法律風(fēng)險(xiǎn)的排序和分級(jí)，劃分出需要重點(diǎn)關(guān)注和優(yōu)先應(yīng)對(duì)的法律風(fēng)險(xiǎn)。事實(shí)上，法律風(fēng)險(xiǎn)評(píng)估的合理定量化有望成為下一步企業(yè)法律風(fēng)險(xiǎn)管理理論和實(shí)踐的焦點(diǎn)問題。
4.制定企業(yè)法律風(fēng)險(xiǎn)應(yīng)對(duì)措施。風(fēng)險(xiǎn)應(yīng)對(duì)包括檢查風(fēng)險(xiǎn)應(yīng)對(duì)現(xiàn)狀、選擇風(fēng)險(xiǎn)應(yīng)對(duì)策略和制定風(fēng)險(xiǎn)應(yīng)對(duì)計(jì)劃三個(gè)環(huán)節(jié)。在盤點(diǎn)應(yīng)對(duì)現(xiàn)狀時(shí)，考慮現(xiàn)有的人員組織、獎(jiǎng)懲機(jī)制、能力素質(zhì)，經(jīng)費(fèi)供給等是否能滿足法律風(fēng)險(xiǎn)應(yīng)對(duì)需要，為選擇應(yīng)對(duì)策略和制定計(jì)劃提供支撐；在選擇應(yīng)對(duì)策略時(shí)，應(yīng)綜合運(yùn)用多種策略，如規(guī)避風(fēng)險(xiǎn)、控制風(fēng)險(xiǎn)、轉(zhuǎn)移風(fēng)險(xiǎn)、接受風(fēng)險(xiǎn)等；在制定風(fēng)險(xiǎn)應(yīng)對(duì)計(jì)劃時(shí)，要考慮應(yīng)對(duì)計(jì)劃應(yīng)有的機(jī)構(gòu)和人員安排，相應(yīng)責(zé)任要求，措施的優(yōu)先次序和計(jì)劃實(shí)施時(shí)間表。
5.實(shí)施企業(yè)法律風(fēng)險(xiǎn)管理措施。按既定的風(fēng)險(xiǎn)管理計(jì)劃方案，保證資源配置到位，信息溝通順暢，把法律風(fēng)險(xiǎn)管理實(shí)施工作切實(shí)融入到企業(yè)的日常管理工作當(dāng)中去。風(fēng)險(xiǎn)管理措施的實(shí)施，不是靠法務(wù)部門或者法務(wù)總監(jiān)單個(gè)主體去完成。因?yàn)轱L(fēng)險(xiǎn)管理計(jì)劃，必然涉及不同層面和職位的企業(yè)人員。對(duì)于法律風(fēng)險(xiǎn)管理計(jì)劃方案的執(zhí)行，法務(wù)人員（律師）的最主要作用就是宣貫、培訓(xùn)。6.對(duì)法律風(fēng)險(xiǎn)實(shí)施情況進(jìn)行監(jiān)督和反饋。企業(yè)應(yīng)及時(shí)監(jiān)督和反饋法律風(fēng)險(xiǎn)管理流程的運(yùn)行狀況，并根據(jù)發(fā)現(xiàn)的問題對(duì)法律風(fēng)險(xiǎn)管理工作進(jìn)行持續(xù)改進(jìn)，以形成一個(gè)完整的法律風(fēng)險(xiǎn)管理流程閉環(huán)。
五、法律風(fēng)險(xiǎn)管理模式
企業(yè)法律風(fēng)險(xiǎn)管理模式是指企業(yè)法律風(fēng)險(xiǎn)管理的入手點(diǎn)和整體框架。模式在各企業(yè)中也表現(xiàn)不一，它與企業(yè)的管理實(shí)踐密切相關(guān)。有三種常見的模式。
1.根據(jù)企業(yè)的主要經(jīng)營管理活動(dòng)來建立企業(yè)法律風(fēng)險(xiǎn)管理模式。即從企業(yè)的投資活動(dòng)、生產(chǎn)活動(dòng)、營銷活動(dòng)、采購活動(dòng)、研發(fā)、人力資源管理活動(dòng)，財(cái)務(wù)管理活動(dòng)等一系列活動(dòng)入手，發(fā)現(xiàn)每一項(xiàng)經(jīng)營管理活動(dòng)中可能存在的法律風(fēng)險(xiǎn)，然后運(yùn)用本企業(yè)法律風(fēng)險(xiǎn)管理流程對(duì)其進(jìn)行梳理、評(píng)估、應(yīng)對(duì)。有些企業(yè)的經(jīng)營管理活動(dòng)可能偏于投資，有些企業(yè)又可能偏于研發(fā)，還有些企業(yè)會(huì)偏于營銷等等，根據(jù)企業(yè)重點(diǎn)的經(jīng)營管理活動(dòng)，投入主要的法律風(fēng)險(xiǎn)管理資源，以最大化地達(dá)到法律風(fēng)險(xiǎn)管理效果。2.根據(jù)不同的法律領(lǐng)域來建立企業(yè)法律風(fēng)險(xiǎn)管理模式。即從合同法、知識(shí)產(chǎn)權(quán)法、勞動(dòng)法、招投標(biāo)法、投資法、稅法、競(jìng)爭(zhēng)法，訴訟法等部門法的角度入手，發(fā)現(xiàn)每一個(gè)部門法所對(duì)應(yīng)的企業(yè)經(jīng)營活動(dòng)中存在的法律風(fēng)險(xiǎn)，結(jié)合本企業(yè)法律風(fēng)險(xiǎn)管理流程，實(shí)施法律風(fēng)險(xiǎn)管理行為。這種法律風(fēng)險(xiǎn)管理模式優(yōu)點(diǎn)是法律性強(qiáng)，框架清晰，但缺點(diǎn)是企業(yè)的某項(xiàng)經(jīng)營管理行為可能會(huì)包含多個(gè)部門法，會(huì)導(dǎo)致內(nèi)容交叉或遺漏的情況。
3.根據(jù)企業(yè)發(fā)展階段來建立企業(yè)法律風(fēng)險(xiǎn)管理模式。即從企業(yè)設(shè)立、運(yùn)營、擴(kuò)張、消滅等四階段來分析每一階段的重點(diǎn)法律風(fēng)險(xiǎn)。如企業(yè)設(shè)立階段，要從企業(yè)的法律形態(tài)、治理結(jié)構(gòu)來考慮法律風(fēng)險(xiǎn)。不同的法律形態(tài)，如有限責(zé)任公司制與有限合伙制，對(duì)于投資者來說，即意味著不同的法律風(fēng)險(xiǎn)結(jié)構(gòu)。不僅企業(yè)控制權(quán)不同，而且股東稅負(fù)也不相同，當(dāng)然也就帶來不同的風(fēng)險(xiǎn)處理方案。在企業(yè)擴(kuò)張階段，要考慮大量投資并購、融資可能帶來的風(fēng)險(xiǎn)，并能制定方案適應(yīng)這些風(fēng)險(xiǎn)的識(shí)別、評(píng)估和應(yīng)對(duì)。
當(dāng)然，還存在其他的法律風(fēng)險(xiǎn)管理模式，如從法律風(fēng)險(xiǎn)源，企業(yè)職能部門、企業(yè)部門服務(wù)內(nèi)部定價(jià)等角度進(jìn)行梳理、評(píng)估企業(yè)面臨的法律風(fēng)險(xiǎn)，由企業(yè)根據(jù)自身實(shí)際情況而定。
七、法律風(fēng)險(xiǎn)管理績(jī)效
企業(yè)法律風(fēng)險(xiǎn)管理目的在于促進(jìn)企業(yè)戰(zhàn)略目標(biāo)的實(shí)現(xiàn)。對(duì)企業(yè)法律風(fēng)險(xiǎn)管理是否給企業(yè)的業(yè)績(jī)提升乃至戰(zhàn)略實(shí)現(xiàn)帶來積極影響以及影響的程度進(jìn)行評(píng)價(jià)是關(guān)系到該管理行為是否最終有效的依據(jù)。法律風(fēng)險(xiǎn)管理要形成長效機(jī)制，必須有自身的績(jī)效制度?？?jī)效分整體績(jī)效與個(gè)體績(jī)效。整體績(jī)效指本企業(yè)或法律風(fēng)險(xiǎn)管理系統(tǒng)的投入與產(chǎn)出的關(guān)系。企業(yè)要根據(jù)自身情況設(shè)計(jì)一套實(shí)施法律風(fēng)險(xiǎn)管理績(jī)效評(píng)估的體系，明確企業(yè)和企業(yè)某個(gè)部門在法律風(fēng)險(xiǎn)管理的投入與收益情況，以更好地控制成本，提高收益。
法律風(fēng)險(xiǎn)管理成本可作為衡量企業(yè)在獲得同樣利潤時(shí)的健康度和持久度。如某個(gè)企業(yè)花費(fèi)了更大的法律風(fēng)險(xiǎn)管理成本，才達(dá)到其他企業(yè)同等利潤水平，那么這個(gè)企業(yè)的發(fā)展可以認(rèn)為是存在法律風(fēng)險(xiǎn)的，是不可持續(xù)的，除非其能改變現(xiàn)狀。
就法律風(fēng)險(xiǎn)管理的個(gè)體績(jī)效而言，首先是指對(duì)執(zhí)行企業(yè)法律風(fēng)險(xiǎn)系統(tǒng)中的某一項(xiàng)行為后果進(jìn)行考核，并與其個(gè)人利益掛鉤。然后，進(jìn)行個(gè)體績(jī)效評(píng)價(jià)。更重要的是可以將個(gè)人在法律風(fēng)險(xiǎn)管理執(zhí)行中的考核責(zé)任轉(zhuǎn)化為個(gè)人工作動(dòng)力。
適當(dāng)?shù)姆娠L(fēng)險(xiǎn)管理績(jī)效考核能將企業(yè)各層級(jí)人員在制定和實(shí)施法律風(fēng)險(xiǎn)管理措施的過程前后聯(lián)結(jié)起來，促使法律風(fēng)險(xiǎn)管理真正走向定量化管理。
第四篇：三層架構(gòu)應(yīng)用總結(jié)——.net
ASP.NET三層架構(gòu)應(yīng)用總結(jié)
與ASP相比ASP.NET在Web應(yīng)用開發(fā)上無疑更容易，更有效率。Web開發(fā)大部分還是圍繞著數(shù)據(jù)操作，建立數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)，編寫代碼訪問和修改數(shù)據(jù)，設(shè)計(jì)界面采集和呈現(xiàn)數(shù)據(jù)。走過Asp.net學(xué)習(xí)入門階段后，真正開始著手開發(fā)一個(gè)Web項(xiàng)目時(shí)，才發(fā)現(xiàn)錯(cuò)綜復(fù)雜的數(shù)據(jù)與關(guān)聯(lián)根本就不是SqlDataSource和AccessDataSource數(shù)據(jù)源控件能簡(jiǎn)單解決的，而恰恰是被忽視了的一個(gè)ObjectDataSource數(shù)據(jù)源控件才是真正踏入開發(fā)門檻的關(guān)鍵，由此也對(duì)三層架構(gòu)模式有了初步體驗(yàn)。
一．ASP.NET三層架構(gòu)介紹
設(shè)計(jì)模式中的分層架構(gòu)（可以參考一下J2EE中MVC模式）實(shí)現(xiàn)了各司其職，互不干涉，所以如果一旦哪一層的需求發(fā)生了變化，就只需要更改相應(yīng)的層中的代碼而不會(huì)影響到其它層中的代碼。這樣就能更好的實(shí)現(xiàn)開發(fā)中的分工，有利于組件的重用。所以這些年關(guān)于模式的研究有很多成果，應(yīng)用也很廣泛。一個(gè)好的模式在程序開發(fā)和后期維護(hù)中作用重大。ASP.NET三層架構(gòu)自底向上分為：數(shù)據(jù)訪問層（DAL），業(yè)務(wù)邏輯層（BLL）和表示層（PL）。
數(shù)據(jù)訪問層（DAL）：使用了一個(gè)強(qiáng)類型的DataSet作為數(shù)據(jù)訪問層，只是單純的對(duì)數(shù)據(jù)進(jìn)行增，刪，改，查詢和判斷存在等等較通用的數(shù)據(jù)訪問方法（由SQL語句來提供），不應(yīng)該有“事務(wù)”存在。
業(yè)務(wù)邏輯層（BLL）：業(yè)務(wù)邏輯層是在數(shù)據(jù)訪問層和表示層之間進(jìn)行數(shù)據(jù)交換的橋梁，按業(yè)務(wù)需求調(diào)用數(shù)據(jù)訪問層中的方法組合，集合了各種業(yè)務(wù)規(guī)則到一個(gè)BLL中，例如通過條件進(jìn)行判斷的數(shù)據(jù)操作或“事務(wù)”處理。BLL都是以類庫（Class Library）的形式來實(shí)現(xiàn)的。
表示層（PL）：表示層是為客戶提供用于交互的應(yīng)用服務(wù)圖形界面，幫助用戶理解和高效地定位應(yīng)用服務(wù)，呈現(xiàn)業(yè)務(wù)邏輯層中傳遞的數(shù)據(jù)，用ASP.NET頁面來實(shí)現(xiàn)。
二．三層架構(gòu)應(yīng)用實(shí)現(xiàn) 隨著ASP.NET 的不斷升級(jí)，可以很方便的使用ASP.NET 來構(gòu)建B/S 三層架構(gòu)的應(yīng)用程序，下面以“教師業(yè)務(wù)信息管理系統(tǒng)”項(xiàng)目中的部分例子來演示如何使用ASP.NET 2.0 和SQL Server 2005數(shù)據(jù)庫來構(gòu)建一個(gè)三層架構(gòu)的應(yīng)用程序。
1．創(chuàng)建數(shù)據(jù)庫
打開SQL Server 2005，新建一個(gè)數(shù)據(jù)庫“TeacherDb”，建立如下所示結(jié)構(gòu)的兩個(gè)表“PersonInfo”和“JobInfo”。兩表以PersonIDNumber作為關(guān)聯(lián)字段，存儲(chǔ)18位身份證號(hào)碼。
2．創(chuàng)建數(shù)據(jù)訪問層 在開始創(chuàng)建數(shù)據(jù)訪問層(DAL)之前，首先需要?jiǎng)?chuàng)建一個(gè)網(wǎng)站，配置好數(shù)據(jù)庫鏈接。
第一步：創(chuàng)建一個(gè)Web項(xiàng)目，配置數(shù)據(jù)庫連接
打開Visual Studio 2005（以下簡(jiǎn)稱VS2005）集成開發(fā)環(huán)境, 首先創(chuàng)建一個(gè)C#語言的ASP.NET網(wǎng)站，并將其命名為WebSite，設(shè)置位置(Location)列表的選項(xiàng)為文件系統(tǒng)(File System)，然后選這一個(gè)放置這個(gè)網(wǎng)站的文件夾，然后選擇編程語言為C#。Visual Studio會(huì)為你生成一個(gè)新的網(wǎng)站，同時(shí)生成一個(gè)名為Default.aspx的網(wǎng)頁，和一個(gè)App_Data文件夾。
第二步：創(chuàng)建數(shù)據(jù)訪問層，配置數(shù)據(jù)庫連接
接下來創(chuàng)建數(shù)據(jù)訪問層，添加一個(gè)強(qiáng)類型的DataSet。在解決方案管理器里的項(xiàng)目節(jié)點(diǎn)上按右鼠標(biāo)，選擇“添加新項(xiàng)”，在模板列單里選擇“數(shù)據(jù)集”，將其命名為DataSet1.xsd。接下來會(huì)出現(xiàn)“TableAdpater”配置向?qū)У拇翱冢x擇數(shù)據(jù)庫服務(wù)器，設(shè)置好各項(xiàng)參數(shù)，并按照提示逐步完成。需要注意: 1．指定連接的數(shù)據(jù)庫字符串，并選擇將連接字符串保存到web.config文件中去。
2．命令類型選擇“使用SQL語句”，通過“高級(jí)選項(xiàng)”選擇“生成Insert、Update和Delete語句”，通過“查詢生成器”生成要裝載數(shù)據(jù)的“Select語句”。并為方法命名。
http://apps.hi.baidu.com/share/detail/37462037 資料二
引言：本文不是從理論的角度來探討三層架構(gòu)，而是用一個(gè)示例來介紹如何建設(shè)一個(gè)三層架構(gòu)的項(xiàng)目，并說明項(xiàng)目中各個(gè)文件所處的層次與作用。寫本文的目的，不是為了說明自己的這個(gè)方法有多對(duì)，別人的肯定不對(duì)，而是希望給那些初學(xué)三層架構(gòu)卻不知從何入手的朋友提供一點(diǎn)幫助。因?yàn)榫W(wǎng)上的文章，大多是注重理論的介紹，而忽略了具體的實(shí)踐應(yīng)用，或者有示例但講得不透徹。導(dǎo)致看了之后，理論上又學(xué)習(xí)了一遍，但還是不知道代碼怎么寫。所以想從這個(gè)方面入手寫一下，讓從來沒做過三層架構(gòu)的初學(xué)者也能照貓畫虎，寫出代碼來。文章表述的是筆者個(gè)人對(duì)三層架構(gòu)的認(rèn)識(shí)，肯定有許多不足的地方，歡迎大家指正，小弟也會(huì)根據(jù)反饋來修改這篇文章。文中的代碼是偽代碼，僅用來闡明思路。
正文：
一提三層架構(gòu)，大家都知道是表現(xiàn)層（UI），業(yè)務(wù)邏輯層（BLL）和數(shù)據(jù)訪問層（DAL），而且每層如何細(xì)分也都有很多的方法。但具體代碼怎么寫，到底那些文件算在哪一層，卻是模模糊糊的。下面用一個(gè)簡(jiǎn)單的例子來帶領(lǐng)大家實(shí)戰(zhàn)三層架構(gòu)的項(xiàng)目，這個(gè)例子只有一個(gè)功能，就是用戶的簡(jiǎn)單管理。
首先建立一個(gè)空白解決方案，添加如下項(xiàng)目及文件
1、添加ASP.NET Web Application項(xiàng)目，命名為UI，新建Web Form類型文件User.aspx（含User.aspx.cs）
2、添加ClassLibrary項(xiàng)目，命名為BLL，新建Class類型文件UserBLL.cs
3、添加ClassLibrary項(xiàng)目，命名為DAL，新建Class類型文件UserDAL.cs。添加SQLHelper引用。（這個(gè)是微軟的數(shù)據(jù)訪問類，也可以不用，直接編寫所有的數(shù)據(jù)訪問代碼。我一般用自己寫的數(shù)據(jù)訪問類DataAccessHelper）。
4、添加ClassLibrary項(xiàng)目，命名為Model，新建Class類型文件UserModel.cs
5、添加ClassLibrary項(xiàng)目，命名為IDAL，新建Interface類型文件IUserDAL.cs
6、添加ClassLibrary項(xiàng)目，命名為ClassFactory 相信大家已經(jīng)看出來了，這個(gè)和Petshop的示例沒什么區(qū)別，而且更簡(jiǎn)單，因?yàn)樵谙乱彩峭ㄟ^Petshop學(xué)習(xí)三層架構(gòu)的。但一些朋友對(duì)于這幾個(gè)項(xiàng)目所處的層次，以及它們之間的關(guān)系，可能比較模糊，這里逐個(gè)說明一下：
1、User.aspx和User.aspx.cs 這兩個(gè)文件（以及文件所屬的項(xiàng)目，下面也是如此，不再重復(fù)強(qiáng)調(diào)了）都屬于表現(xiàn)層部分。User.aspx比較好理解，因?yàn)樗褪秋@示頁面了。User.aspx.cs有些人覺得不應(yīng)該算，而是要?jiǎng)澋綐I(yè)務(wù)邏輯層中去。如果不做分層的話，那么讓User.aspx.cs來處理業(yè)務(wù)邏輯，甚至操作數(shù)據(jù)庫都沒什么問題，但是做分層的話，這樣就不應(yīng)該了。在分層結(jié)構(gòu)中，User.aspx.cs僅應(yīng)該處理與顯示有關(guān)的內(nèi)容，其它部分都不應(yīng)該涉及。
舉例：我們實(shí)現(xiàn)用列表方式顯示用戶的功能，那么提取信息的工作是由BLL來做的，UI（本例中是User.aspx.cs）調(diào)用BLL得到UserInfo后，通過代碼綁定到User.aspx的數(shù)據(jù)控件上，就實(shí)現(xiàn)了列表的顯示。在此過程中User.aspx.cs對(duì)UI沒有起到什么作用，僅是用來傳遞數(shù)據(jù)，而且因?yàn)閷?shí)際編碼中大部分情況都是如此的實(shí)現(xiàn)，所以使有些人覺得User.aspx.cs不應(yīng)該算UI，而應(yīng)該并入BLL負(fù)責(zé)邏輯處理。繼續(xù)往下看，這時(shí)提出了一個(gè)新需求，要求在每個(gè)用戶的前面加一個(gè)圖標(biāo)，生動(dòng)地表現(xiàn)出用戶的性別，而且不滿18歲的用兒童圖標(biāo)表示。這個(gè)需求的實(shí)現(xiàn)，就輪到User.aspx.cs來做了，這種情況下User.aspx.cs才算有了真正的用途。
2、NewBLL.cs 添加如下方法：
public IList
public UserInfo GetUser(int UserId)：返回指定用戶的詳細(xì)信息
public bool AddUser(UserInfo User)：新增用戶信息
public bool ChangeUser(UserInfo User)：更新用戶信息
public void RemoveUser(int UserId)：移除用戶信息
此文件就屬于業(yè)務(wù)邏輯層了，專門用來處理與業(yè)務(wù)邏輯有關(guān)的操作?？赡苡泻芏嗳擞X得這一層唯一的用途，就是把表現(xiàn)層傳過來的數(shù)據(jù)轉(zhuǎn)發(fā)給數(shù)據(jù)層。這種情況確實(shí)很多，但這只能說明項(xiàng)目比較簡(jiǎn)單，或者項(xiàng)目本身與業(yè)務(wù)的關(guān)系結(jié)合的不緊密（比如當(dāng)前比較流行的MIS），所以造成業(yè)務(wù)層無事可做，只起到了一個(gè)轉(zhuǎn)發(fā)的作用。但這不代表業(yè)務(wù)層可有可無，隨著項(xiàng)目的增大，或者業(yè)務(wù)關(guān)系比較多，業(yè)務(wù)層就會(huì)體現(xiàn)出它的作用來了。
此處最可能造成錯(cuò)誤的，就是把數(shù)據(jù)操作代碼劃在了業(yè)務(wù)邏輯層，而把數(shù)據(jù)庫作為了數(shù)據(jù)訪問層。
舉例：有些朋友感覺BLL層意義不大，只是將DAL的數(shù)據(jù)提上來就轉(zhuǎn)發(fā)給了UI，而未作任何處理?？匆幌逻@個(gè)例子
BLL層
SelectUser（UserInfo userInfo）根據(jù)傳入的username或email得到用戶詳細(xì)信息。
IsExist（UserInfo userInfo）判斷指定的username或email是否存在。
然后DAL也相應(yīng)提供方法共BLL調(diào)用
SelectUser（UserInfo userInfo）
IsExist（UserInfo userInfo）這樣BLL確實(shí)只起到了一個(gè)傳遞的作用。
但如果這樣做：
BLL.IsExist（Userinfo userinfo）
{ UerInfo user = DAL.SelectUser（User）；
return(userInfo.Id!= null);
} 那么DAL就無需實(shí)現(xiàn)IsExist()方法了，BLL中也就有了邏輯處理的代碼。
3、UserModel.cs 實(shí)體類，這個(gè)東西，大家可能覺得不好分層。包括我以前在內(nèi)，是這樣理解的：UI?àModel?àBLL?àModel?àDAL，如此則認(rèn)為Model在各層之間起到了一個(gè)數(shù)據(jù)傳輸?shù)臉蛄鹤饔?。不過在這里，我們不是把事情想簡(jiǎn)單，而是想復(fù)雜了。
Model是什么？它什么也不是！它在三層架構(gòu)中是可有可無的。它其實(shí)就是面向?qū)ο缶幊讨凶罨镜臇|西：類。一個(gè)桌子是一個(gè)類，一條新聞也是一個(gè)類，int、string、doublie等也是類，它僅僅是一個(gè)類而已。
這樣，Model在三層架構(gòu)中的位置，和int，string等變量的地位就一樣了，沒有其它的目的，僅用于數(shù)據(jù)的存儲(chǔ)而已，只不過它存儲(chǔ)的是復(fù)雜的數(shù)據(jù)。所以如果你的項(xiàng)目中對(duì)象都非常簡(jiǎn)單，那么不用Model而直接傳遞多個(gè)參數(shù)也能做成三層架構(gòu)。
那為什么還要有Model呢，它的好處是什么呢。下面是思考一個(gè)問題時(shí)想到的，插在這里：
Model在各層參數(shù)傳遞時(shí)到底能起到做大的作用？
在各層間傳遞參數(shù)時(shí)，可以這樣：
AddUser（userId，userName，userPassword，…，）
也可以這樣：
AddUser（userInfo）
這兩種方法那個(gè)好呢。一目了然，肯定是第二種要好很多。
什么時(shí)候用普通變量類型（int,string,guid,double）在各層之間傳遞參數(shù)，什么使用Model傳遞？下面幾個(gè)方法：
SelectUser（int UserId）
SelectUserByName（string username）
SelectUserByName（string username，string password）
SelectUserByEmail（string email）
SelectUserByEmail（string email，string password）
可以概括為：
SelectUser（userId）
SelectUser（user）
這里用user這個(gè)Model對(duì)象囊括了username，password，email這三個(gè)參數(shù)的四種組合模式。UserId其實(shí)也可以合并到user中，但項(xiàng)目中其它BLL都實(shí)現(xiàn)了帶有id參數(shù)的接口，所以這里也保留這一項(xiàng)。
傳入了userInfo，那如何處理呢，這個(gè)就需要按照先后的順序了，有具體代碼決定。
這里按這個(gè)順序處理
首先看是否同時(shí)具有username和password，然后看是否同時(shí)具有email和password，然后看是否有username，然后看是否有email。依次處理。
這樣，如果以后增加一個(gè)新內(nèi)容，會(huì)員卡（number），則無需更改接口，只要在DAL的代碼中增加對(duì)number的支持就行，然后前臺(tái)增加會(huì)員卡一項(xiàng)內(nèi)容的表現(xiàn)與處理即可。
4、UserDAL.cs public IList
public UserInfo SelectUser(int UserId)：返回指定用戶的相信信息
public bool InsertUser(UserInfo User)：新增用戶信息
public bool UpdateUser(UserInfo User)：更新用戶信息
public void DeleteUser(int UserId)：移除用戶信息
很多人最鬧不清的就是數(shù)據(jù)訪問層，到底那部分才算數(shù)據(jù)訪問層呢？有些認(rèn)為數(shù)據(jù)庫就是數(shù)據(jù)訪問層，這是對(duì)定義沒有搞清楚，DAL是數(shù)據(jù)訪問層而不是數(shù)據(jù)存儲(chǔ)層，因此數(shù)據(jù)庫不可能是這一層的。也有的把SQLHelper（或其同類作用的組件）作為數(shù)據(jù)訪問層，它又是一個(gè)可有可無的東西，SQLHelper的作用是減少重復(fù)性編碼，提高編碼效率，因此如果我習(xí)慣在乎效率或使用一個(gè)非數(shù)據(jù)庫的數(shù)據(jù)源時(shí)，可以丟棄SQLHelper，一個(gè)可以隨意棄置的部分，又怎么能成為三層架構(gòu)中的一層呢。
可以這樣定義：與數(shù)據(jù)源操作有關(guān)的代碼，就應(yīng)該放在數(shù)據(jù)訪問層中，屬于數(shù)據(jù)訪問層
5、IUserDAL 數(shù)據(jù)訪問層接口，這又是一個(gè)可有可無的東西，因?yàn)镻etshop中帶了它和ClassFactory類工廠，所以有些項(xiàng)目不論需不需要支持多數(shù)據(jù)源，都把這兩個(gè)東西做了進(jìn)來，有的甚至不建ClassFactory而只建了IDAL，然后“IUserDAL iUserDal = new UserDAL();”，不知意義何在。這就完全是畫虎不成反類犬了。
許多人在這里有一個(gè)誤解，那就是以為存在這樣的關(guān)系：BLL?àIDAL?àDAL，認(rèn)為IDAL起到了BLL和DAL之間的橋梁作用，BLL是通過IDAL來調(diào)用DAL的。但實(shí)際是即使你如此編碼：“IUserDAL iUserDal = ClassFacotry.CreateUserDAL()；”，那么在執(zhí)行“iUserDal.SelectUsers()”時(shí)，其實(shí)還是執(zhí)行的UserDAL實(shí)例，而不是IUserDAL實(shí)例，所以IDAL在三層中的位置是與DAL平級(jí)的關(guān)系。
通過上面的介紹，基本上將三層架構(gòu)的層次結(jié)構(gòu)說明了。其實(shí)，本人有一個(gè)判斷三層架構(gòu)是否標(biāo)準(zhǔn)的方法，那就是將三層中的任意一層完全替換，都不會(huì)對(duì)其它兩層造成影響，這樣的構(gòu)造基本就符合三層標(biāo)準(zhǔn)了（雖然實(shí)現(xiàn)起來比較難^_^）。例如如果將項(xiàng)目從B/S改為C/S（或相反），那么除了UI以外，BLL與DAL都不用改動(dòng)；或者將SQLServer改為Oracle，只需替換SQLServerDAL到OracleDAL，無需其它操作等等。本來想在文中加入一些具體的代碼的，但感覺不是很必要，如果大家覺得需要的話，我再補(bǔ)充吧。
總結(jié)：不要因?yàn)槟硞€(gè)層對(duì)你來說沒用，或者實(shí)現(xiàn)起來特別簡(jiǎn)單，就認(rèn)為它沒有必要，或者摒棄它，或者挪作它用。只要進(jìn)行了分層，不管是幾層，每一層都要有明確的目的和功能實(shí)現(xiàn)，而不要被實(shí)際過程所左右，造成同一類文件位于不同層的情況發(fā)生。也不要出現(xiàn)同一層實(shí)現(xiàn)了不同的功能的情況發(fā)生。
資料三
三層結(jié)構(gòu)”是“外觀層”、“商業(yè)邏輯層”、“數(shù)據(jù)庫層”
假設(shè)以這樣的結(jié)構(gòu)制作一個(gè)留言板，那么應(yīng)該是：
# 留言板頁面的外觀代碼都存放在.aspx 文件中
# 當(dāng)用戶點(diǎn)擊頁面上的提交按鈕時(shí)，先將文本信息傳遞給一個(gè) LeaveWord 類對(duì)象（LeaveWord 類的定義被封裝到“商業(yè)邏輯層”）
# 之后讓這個(gè)對(duì)象執(zhí)行 Post()將留言信息發(fā)送到數(shù)據(jù)庫
用一個(gè)簡(jiǎn)單的代碼就是：
//---------// 在外觀層，當(dāng)用戶點(diǎn)擊發(fā)送按鈕后
//---------private void Post_ServerClick(object sender, EventArgs e){ LeaveWord lword=new LeaveWord();lword.Content=Content.Value;lword.Post();}
//---------// 在商業(yè)邏輯層，定義 LeaveWord 類
//---------public class LeaveWord { public string Content;
public void Post(){ new LWordData().Post(this.Content);} }
//---------// 數(shù)據(jù)庫層，定義發(fā)送方法
//---------public class LWordData { public void Post(string content){ // 打開數(shù)據(jù)庫，將 content 插入到表中
} } 這樣，外觀層就不必費(fèi)心數(shù)據(jù)庫操作了...理解基本正確.但是數(shù)據(jù)層已經(jīng)只是數(shù)據(jù)庫的操作,不應(yīng)該和業(yè)務(wù)有任何關(guān)系,你可以參考SqlHelper.cs 提醒一點(diǎn),系統(tǒng)的“層”是對(duì)代碼的一種邏輯劃分,并不是一定要三層,假設(shè)你的系統(tǒng)很簡(jiǎn)單,就一個(gè)頁面,那一層就可以,如果系統(tǒng)很復(fù)雜,也可能是n層.差不離了，核心就是外層絕對(duì)不會(huì)涉及任何數(shù)據(jù)處理，他的任務(wù)是設(shè)置界面，獲取數(shù)據(jù)，輸出數(shù)據(jù)
業(yè)務(wù)層最重要，所有數(shù)據(jù)處理在這里，如何運(yùn)用外層提供的數(shù)據(jù)處理業(yè)務(wù) 數(shù)據(jù)庫層一般都建議調(diào)用存儲(chǔ)過程，返回?cái)?shù)據(jù)集或其他所需數(shù)據(jù);.net的那兩個(gè)例子很好，多學(xué)習(xí)一下.一個(gè)原則： 上層調(diào)下層
上層對(duì)下層是不可見的
設(shè)計(jì)時(shí)，表現(xiàn)層只調(diào)用邏輯層，表現(xiàn)層主要是取得頁面的數(shù)據(jù)傳到邏輯層，和把從邏輯層得到的數(shù)據(jù)顯示到頁面上。
邏輯層負(fù)責(zé)把數(shù)據(jù)加工整理傳到數(shù)據(jù)層和把從數(shù)據(jù)層取得的數(shù)據(jù)加工 數(shù)據(jù)層就只負(fù)責(zé)把數(shù)據(jù)對(duì)數(shù)據(jù)庫操作
業(yè)務(wù)邏輯層 就是給上層和下層下達(dá)命令和調(diào)節(jié)行為的中間層
資料四：基于組件的三層B/S結(jié)構(gòu)概述
在軟件體系架構(gòu)設(shè)計(jì)中，分層式結(jié)構(gòu)是最常見，也是最重要的一種結(jié)構(gòu)。微軟推薦的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層（又或成為領(lǐng)域?qū)樱?、表示層。三層結(jié)構(gòu)原理
3個(gè)層次中，系統(tǒng)主要功能和業(yè)務(wù)邏輯都在業(yè)務(wù)邏輯層進(jìn)行處理。
所謂三層體系結(jié)構(gòu)，是在客戶端與數(shù)據(jù)庫之間加入了一個(gè)“中間層”，也叫組件層。這里所說的三層體系，不是指物理上的三層，不是簡(jiǎn)單地放置三臺(tái)機(jī)器就是三層體系結(jié)構(gòu)，也不僅僅有B/S應(yīng)用才是三層體系結(jié)構(gòu)，三層是指邏輯上的三層，即使這三個(gè)層放置到一臺(tái)機(jī)器上。三層體系的應(yīng)用程序?qū)I(yè)務(wù)規(guī)則、數(shù)據(jù)訪問、合法性校驗(yàn)等工作放到了中間層進(jìn)行處理。通常情況下，客戶端不直接與數(shù)據(jù)庫進(jìn)行交互，而是通過COM/DCOM通訊與中間層建立連接，再經(jīng)由中間層與數(shù)據(jù)庫進(jìn)行交互。表示層
位于最外層（最上層），離用戶最近。用于顯示數(shù)據(jù)和接收用戶輸入的數(shù)據(jù)，為用戶提供一種交互式操作的界面 業(yè)務(wù)邏輯層
業(yè)務(wù)邏輯層（Business Logic Layer）無疑是系統(tǒng)架構(gòu)中體現(xiàn)核心價(jià)值的部分。它的關(guān)注點(diǎn)主要集中在業(yè)務(wù)規(guī)則的制定、業(yè)務(wù)流程的實(shí)現(xiàn)等與業(yè)務(wù)需求有關(guān)的系統(tǒng)設(shè)計(jì)，也即是說它是與系統(tǒng)所應(yīng)對(duì)的領(lǐng)域（Domain）邏輯有關(guān)，很多時(shí)候，也將業(yè)務(wù)邏輯層稱為領(lǐng)域?qū)印＠鏜artin Fowler在《Patterns of Enterprise Application Architecture》一書中，將整個(gè)架構(gòu)分為三個(gè)主要的層：表示層、領(lǐng)域?qū)雍蛿?shù)據(jù)源層。作為領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的先驅(qū)Eric Evans，對(duì)業(yè)務(wù)邏輯層作了更細(xì)致地劃分，細(xì)分為應(yīng)用層與領(lǐng)域?qū)樱ㄟ^分層進(jìn)一步將領(lǐng)域邏輯與領(lǐng)域邏輯的解決方案分離。
業(yè)務(wù)邏輯層在體系架構(gòu)中的位置很關(guān)鍵，它處于數(shù)據(jù)訪問層與表示層中間，起到了數(shù)據(jù)交換中承上啟下的作用。由于層是一種弱耦合結(jié)構(gòu)，層與層之間的依賴是向下的，底層對(duì)于上層而言是“無知”的，改變上層的設(shè)計(jì)對(duì)于其調(diào)用的底層而言沒有任何影響。如果在分層設(shè)計(jì)時(shí)，遵循了面向接口設(shè)計(jì)的思想，那么這種向下的依賴也應(yīng)該是一種弱依賴關(guān)系。因而在不改變接口定義的前提下，理想的分層式架構(gòu)，應(yīng)該是一個(gè)支持可抽取、可替換的“抽屜”式架構(gòu)。正因?yàn)槿绱?，業(yè)務(wù)邏輯層的設(shè)計(jì)對(duì)于一個(gè)支持可擴(kuò)展的架構(gòu)尤為關(guān)鍵，因?yàn)樗缪萘藘蓚€(gè)不同的角色。對(duì)于數(shù)據(jù)訪問層而言，它是調(diào)用者；對(duì)于表示層而言，它卻是被調(diào)用者。依賴與被依賴的關(guān)系都糾結(jié)在業(yè)務(wù)邏輯層上，如何實(shí)現(xiàn)依賴關(guān)系的解耦，則是除了實(shí)現(xiàn)業(yè)務(wù)邏輯之外留給設(shè)計(jì)師的任務(wù)。數(shù)據(jù)層
數(shù)據(jù)訪問層：有時(shí)候也稱為是持久層，其功能主要是負(fù)責(zé)數(shù)據(jù)庫的訪問，可以訪問數(shù)據(jù)庫系統(tǒng)、二進(jìn)制文件、文本文檔或是XML文檔。
簡(jiǎn)單的說法就是實(shí)現(xiàn)對(duì)數(shù)據(jù)表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就會(huì)包括對(duì)象和數(shù)據(jù)表之間的mapping，以及對(duì)象實(shí)體的持久化。
第五篇：企業(yè)內(nèi)控應(yīng)用指引第1號(hào)——組織架構(gòu)
企業(yè)內(nèi)部控制應(yīng)用指引第1號(hào)——組織架構(gòu)
第一章 總則
第一條 為了促進(jìn)企業(yè)實(shí)現(xiàn)發(fā)展戰(zhàn)略，優(yōu)化治理結(jié)構(gòu)、管理體制和運(yùn)行機(jī)制，建立現(xiàn)代企業(yè)制度，根據(jù)《中華人民共和國公司法》等有關(guān)法律法規(guī)和《企業(yè)內(nèi)部控制基本規(guī)范》，制定本指引。
第二條 本指引所稱組織架構(gòu)，是指企業(yè)按 照國家有關(guān)法律法規(guī)、股東（大）會(huì)決議和企業(yè)章程，結(jié)合本企業(yè)實(shí)際，明確董事會(huì)、監(jiān)事會(huì)、經(jīng)理層和企業(yè)內(nèi)部各層級(jí)機(jī)構(gòu)設(shè)置、人員編制、職責(zé)權(quán)限、工作程序和相關(guān)要求的制度安排。
第三條 企業(yè)至少應(yīng)當(dāng)關(guān)注組織架構(gòu)設(shè)計(jì)與運(yùn)行中的下列風(fēng)險(xiǎn)：
（一）治理結(jié)構(gòu)形同虛設(shè)，缺乏科學(xué)決策和良性運(yùn)行機(jī)制，可能導(dǎo)致企業(yè)經(jīng)營失敗，難以實(shí)現(xiàn)發(fā)展戰(zhàn)略。
（二）組織架構(gòu)設(shè)計(jì)不科學(xué)，權(quán)責(zé)分配不合理，可能導(dǎo)致機(jī)構(gòu)重疊、職能交叉、推諉扯皮，運(yùn)行效率低下。
第二章 組織架構(gòu)的設(shè)計(jì)
第四條 企業(yè)應(yīng)當(dāng)根據(jù)國家有關(guān)法律法規(guī)的規(guī)定，明確董事會(huì)、監(jiān)事會(huì)和經(jīng)理層的職責(zé)權(quán)限、任職條件、議事規(guī)則和工作程序，確保決策、執(zhí)行和監(jiān)督相互分離，形成制衡。
董事會(huì)對(duì)股東（大）會(huì)負(fù)責(zé)，依法行使企業(yè)的經(jīng)營決策權(quán)。企業(yè)應(yīng)當(dāng)在董事會(huì)下設(shè)立戰(zhàn)略、審計(jì)、薪酬與考核等專門委員會(huì)，明確各專門委員會(huì)的職責(zé)權(quán)限、任職資格、議事規(guī)則和工作程序，為董事會(huì)科學(xué)決策提供支持。
監(jiān)事會(huì)對(duì)股東（大）會(huì)負(fù)責(zé)，監(jiān)督企業(yè)董事、經(jīng)理和其他高級(jí)管理人員依法履行職責(zé)。經(jīng)理層對(duì)董事會(huì)負(fù)責(zé)，主持企業(yè)的生產(chǎn)經(jīng)營管理工作。經(jīng)理和其他高級(jí)管理人員的職責(zé)分工應(yīng)當(dāng)明確。
董事會(huì)、監(jiān)事會(huì)和經(jīng)理層的產(chǎn)生程序應(yīng)當(dāng)合法合規(guī)，其人員構(gòu)成、知識(shí)結(jié)構(gòu)、能力素質(zhì)應(yīng)當(dāng)滿足履行職責(zé)的要求。
第五條 企業(yè)的重大決策、重大事項(xiàng)、重要人事任免及大額資金支付業(yè)務(wù)等，應(yīng)當(dāng)實(shí)行集體決策審批或者聯(lián)簽制度，任何個(gè)人不得單獨(dú)進(jìn)行決策或者擅自改變集體決策意見。
重大決策、重大事項(xiàng)、重要人事任免及大額資金支付業(yè)務(wù)的具體標(biāo)準(zhǔn)由企業(yè)自行確定。第六條 企業(yè)應(yīng)當(dāng)按照科學(xué)、精簡(jiǎn)、高效、制衡的原則，綜合考慮企業(yè)性質(zhì)、發(fā)展戰(zhàn)略、文化理念和管理要求等因素，合理設(shè)置內(nèi)部職能機(jī)構(gòu)，明確各機(jī)構(gòu)的職責(zé)權(quán)限，避免業(yè)務(wù)重復(fù)或職能交叉，形成各司其職、各負(fù)其責(zé)、相互制約、相互協(xié)調(diào)的工作機(jī)制。
第七條 企業(yè)應(yīng)當(dāng)對(duì)各機(jī)構(gòu)的職能進(jìn)行科學(xué)合理的分解，確定各具體職位的名稱、職責(zé)、崗位要求和工作內(nèi)容等，明確各個(gè)崗位的職責(zé)權(quán)限和相互關(guān)系。
企業(yè)在確定職權(quán)和崗位分工過程中，應(yīng)當(dāng)體現(xiàn)不相容職務(wù)相互分離的要求。不相容職務(wù)通常包括：可行性研究與決策審批；決策審批與執(zhí)行；執(zhí)行與監(jiān)督檢查等。
第八條 企業(yè)應(yīng)當(dāng)制定組織結(jié)構(gòu)圖、員工手冊(cè)、業(yè)務(wù)流程圖、崗（職）位說明書和權(quán)限指引等內(nèi)部管理制度或相關(guān)文件，使企業(yè)員工了解和掌握組織架構(gòu)設(shè)計(jì)及權(quán)責(zé)分配情況，正確履行職責(zé)。
第三章
組織架構(gòu)的運(yùn)行
第九條 企業(yè)應(yīng)當(dāng)根據(jù)組織架構(gòu)的設(shè)計(jì)規(guī)范，對(duì)現(xiàn)有治理結(jié)構(gòu)和內(nèi)部機(jī)構(gòu)設(shè)置進(jìn)行全面梳理，確保本企業(yè)治理結(jié)構(gòu)、內(nèi)部機(jī)構(gòu)設(shè)置和運(yùn)行機(jī)制等符合現(xiàn)代企業(yè)制度要求。
企業(yè)梳理治理結(jié)構(gòu)，應(yīng)當(dāng)重點(diǎn)關(guān)注董事、監(jiān)事、經(jīng)理及其他高級(jí)管理人員的任職資格和履職情況，以及董事會(huì)、監(jiān)事會(huì)和經(jīng)理層的運(yùn)行效果。治理結(jié)構(gòu)存在問題的，應(yīng)當(dāng)采取有效措施加以改進(jìn)。
企業(yè)梳理內(nèi)部機(jī)構(gòu)設(shè)置，應(yīng)當(dāng)重點(diǎn)關(guān)注內(nèi)部機(jī)構(gòu)設(shè)置的合理性和運(yùn)行的高效性等。內(nèi)部機(jī)構(gòu)設(shè)置和運(yùn)行中存在職能交叉重疊或運(yùn)行效率低下的，應(yīng)當(dāng)及時(shí)解決。
第十條 企業(yè)擁有子公司的，應(yīng)當(dāng)通過合法有效的形式履行出資人職責(zé)、維護(hù)出資人權(quán)益，特別關(guān)注異地、境外子公司發(fā)展戰(zhàn)略、重大投融資、重大擔(dān)保、重要人事任免、大額資金使用、財(cái)務(wù)預(yù)決算等重要風(fēng)險(xiǎn)領(lǐng)域。
第十一條 企業(yè)應(yīng)當(dāng)定期對(duì)組織架構(gòu)設(shè)計(jì)與運(yùn)行的效率和效果進(jìn)行全面評(píng)估，發(fā)現(xiàn)組織架構(gòu)設(shè)計(jì)與運(yùn)行中存在重要缺陷的，應(yīng)當(dāng)進(jìn)行優(yōu)化調(diào)整。
企業(yè)組織架構(gòu)調(diào)整應(yīng)當(dāng)充分聽取董事、監(jiān)事、高級(jí)管理人員和其他員工的意見，按照規(guī)定的權(quán)限和程序進(jìn)行決策審批。
點(diǎn)擊咨詢 