第一篇：淺談三層架構(gòu)在網(wǎng)站建設中的優(yōu)劣勢

現(xiàn)今網(wǎng)站建設技術(shù)中非常流行使用三層架構(gòu)來開發(fā)和維護網(wǎng)站。通常意義上的三層架構(gòu)就是將整個業(yè)務應用劃分為：表現(xiàn)層（UI）、業(yè)務邏輯層（BLL）、數(shù)據(jù)訪問層（DAL）。區(qū)分層次的目的即為了達到“高內(nèi)聚，低耦合”的思想，在代碼重用性上有著天生的優(yōu)勢。做網(wǎng)站時，使用三層架構(gòu)進行網(wǎng)站建設有什么好處？

1.便于維護與擴展（維護修改代碼方便，層次清晰；擴展方面，添加功能方便，也使程序有較高的可讀性）。

2.便于團隊成員進行分工合作（現(xiàn)在要么以模塊來進行分工，要么是分層來）。

3.可以降低層與層之間的依賴，且有利于開發(fā)標準化。

做網(wǎng)站時，使用三層架構(gòu)進行網(wǎng)站建設的劣勢有哪些？

降低了系統(tǒng)的性能。這是不言而喻的。如果不采用分層式結(jié)構(gòu)，很多業(yè)務可以直接造訪數(shù)據(jù)庫，以此獲取相應的數(shù)據(jù)，如今卻必須通過中間層來完成。當然，對于目前計算機性能配置來說，幾乎可以忽略這方面的劣勢。損失微不足道的性能，而獲得高擴展、高維護性的方式，是程序開發(fā)的王道！

網(wǎng)站建設中三層架構(gòu)各層的作用是什么？

1.數(shù)據(jù)數(shù)據(jù)訪問層:主要是對原始數(shù)據(jù)（數(shù)據(jù)庫或者文本文件等存放數(shù)據(jù)的形式）的操作層，而不是指原始數(shù)據(jù)，也就是說，是對數(shù)據(jù)的操作，而不是數(shù)據(jù)庫,具體為業(yè)務邏輯層或表示層提供數(shù)據(jù)服務。

2.業(yè)務邏輯層:主要是針對具體的問題的操作，也可以理解成對數(shù)據(jù)層的操作,對數(shù)據(jù)業(yè)務邏輯處理，如果說數(shù)據(jù)層是積木，那邏輯層就是對這些積木的搭建。

3.表示層:主要表示W(wǎng)EB方式,也可以表示成WINFORM方式,WEB方式也可以表現(xiàn)成:aspx, 如果邏輯層相當強大和完善,無論表現(xiàn)層如何定義和更改,邏輯層都能完善地提供服務。

使用三層架構(gòu)做出來的網(wǎng)站具有什么特點？

1.高擴展性：添加設備只是對上層應用加以改變，從而輕松達到網(wǎng)站升級的目的。

2.高升級性：網(wǎng)站規(guī)模的擴大和功能的升級對原有技術(shù)不會形成沖擊，而是在原有程序模塊加以升級。

3.負載均衡：減輕服務器負載壓力，達到負載均衡。

綜上所述，我們建議各位開發(fā)者在做網(wǎng)站過程中盡量采用三層架構(gòu)來進行網(wǎng)站建設，以獲得良好的、健康的系統(tǒng)架構(gòu)，而最大程度降低后期的維護成本。北京網(wǎng)站建設公司——千助科技在針對客戶網(wǎng)站進行開發(fā)的過程中，嚴格采用三層架構(gòu)模式，為客戶后期的網(wǎng)站維護、升級節(jié)省了極大的成本。

第二篇：三層架構(gòu)應用總結(jié)——.net

ASP.NET三層架構(gòu)應用總結(jié)

與ASP相比ASP.NET在Web應用開發(fā)上無疑更容易，更有效率。Web開發(fā)大部分還是圍繞著數(shù)據(jù)操作，建立數(shù)據(jù)庫存儲數(shù)據(jù)，編寫代碼訪問和修改數(shù)據(jù)，設計界面采集和呈現(xiàn)數(shù)據(jù)。走過Asp.net學習入門階段后，真正開始著手開發(fā)一個Web項目時，才發(fā)現(xiàn)錯綜復雜的數(shù)據(jù)與關(guān)聯(lián)根本就不是SqlDataSource和AccessDataSource數(shù)據(jù)源控件能簡單解決的，而恰恰是被忽視了的一個ObjectDataSource數(shù)據(jù)源控件才是真正踏入開發(fā)門檻的關(guān)鍵，由此也對三層架構(gòu)模式有了初步體驗。

一．ASP.NET三層架構(gòu)介紹

設計模式中的分層架構(gòu)（可以參考一下J2EE中MVC模式）實現(xiàn)了各司其職，互不干涉，所以如果一旦哪一層的需求發(fā)生了變化，就只需要更改相應的層中的代碼而不會影響到其它層中的代碼。這樣就能更好的實現(xiàn)開發(fā)中的分工，有利于組件的重用。所以這些年關(guān)于模式的研究有很多成果，應用也很廣泛。一個好的模式在程序開發(fā)和后期維護中作用重大。ASP.NET三層架構(gòu)自底向上分為：數(shù)據(jù)訪問層（DAL），業(yè)務邏輯層（BLL）和表示層（PL）。

數(shù)據(jù)訪問層（DAL）：使用了一個強類型的DataSet作為數(shù)據(jù)訪問層，只是單純的對數(shù)據(jù)進行增，刪，改，查詢和判斷存在等等較通用的數(shù)據(jù)訪問方法（由SQL語句來提供），不應該有“事務”存在。

業(yè)務邏輯層（BLL）：業(yè)務邏輯層是在數(shù)據(jù)訪問層和表示層之間進行數(shù)據(jù)交換的橋梁，按業(yè)務需求調(diào)用數(shù)據(jù)訪問層中的方法組合，集合了各種業(yè)務規(guī)則到一個BLL中，例如通過條件進行判斷的數(shù)據(jù)操作或“事務”處理。BLL都是以類庫（Class Library）的形式來實現(xiàn)的。

表示層（PL）：表示層是為客戶提供用于交互的應用服務圖形界面，幫助用戶理解和高效地定位應用服務，呈現(xiàn)業(yè)務邏輯層中傳遞的數(shù)據(jù)，用ASP.NET頁面來實現(xiàn)。

二．三層架構(gòu)應用實現(xiàn) 隨著ASP.NET 的不斷升級，可以很方便的使用ASP.NET 來構(gòu)建B/S 三層架構(gòu)的應用程序，下面以“教師業(yè)務信息管理系統(tǒng)”項目中的部分例子來演示如何使用ASP.NET 2.0 和SQL Server 2005數(shù)據(jù)庫來構(gòu)建一個三層架構(gòu)的應用程序。

1．創(chuàng)建數(shù)據(jù)庫

打開SQL Server 2005，新建一個數(shù)據(jù)庫“TeacherDb”，建立如下所示結(jié)構(gòu)的兩個表“PersonInfo”和“JobInfo”。兩表以PersonIDNumber作為關(guān)聯(lián)字段，存儲18位身份證號碼。

2．創(chuàng)建數(shù)據(jù)訪問層 在開始創(chuàng)建數(shù)據(jù)訪問層(DAL)之前，首先需要創(chuàng)建一個網(wǎng)站，配置好數(shù)據(jù)庫鏈接。

第一步：創(chuàng)建一個Web項目，配置數(shù)據(jù)庫連接

打開Visual Studio 2005（以下簡稱VS2005）集成開發(fā)環(huán)境, 首先創(chuàng)建一個C#語言的ASP.NET網(wǎng)站，并將其命名為WebSite，設置位置(Location)列表的選項為文件系統(tǒng)(File System)，然后選這一個放置這個網(wǎng)站的文件夾，然后選擇編程語言為C#。Visual Studio會為你生成一個新的網(wǎng)站，同時生成一個名為Default.aspx的網(wǎng)頁，和一個App_Data文件夾。

第二步：創(chuàng)建數(shù)據(jù)訪問層，配置數(shù)據(jù)庫連接

接下來創(chuàng)建數(shù)據(jù)訪問層，添加一個強類型的DataSet。在解決方案管理器里的項目節(jié)點上按右鼠標，選擇“添加新項”，在模板列單里選擇“數(shù)據(jù)集”，將其命名為DataSet1.xsd。接下來會出現(xiàn)“TableAdpater”配置向?qū)У拇翱冢x擇數(shù)據(jù)庫服務器，設置好各項參數(shù)，并按照提示逐步完成。需要注意: 1．指定連接的數(shù)據(jù)庫字符串，并選擇將連接字符串保存到web.config文件中去。

2．命令類型選擇“使用SQL語句”，通過“高級選項”選擇“生成Insert、Update和Delete語句”，通過“查詢生成器”生成要裝載數(shù)據(jù)的“Select語句”。并為方法命名。

http://apps.hi.baidu.com/share/detail/37462037 資料二

引言：本文不是從理論的角度來探討三層架構(gòu)，而是用一個示例來介紹如何建設一個三層架構(gòu)的項目，并說明項目中各個文件所處的層次與作用。寫本文的目的，不是為了說明自己的這個方法有多對，別人的肯定不對，而是希望給那些初學三層架構(gòu)卻不知從何入手的朋友提供一點幫助。因為網(wǎng)上的文章，大多是注重理論的介紹，而忽略了具體的實踐應用，或者有示例但講得不透徹。導致看了之后，理論上又學習了一遍，但還是不知道代碼怎么寫。所以想從這個方面入手寫一下，讓從來沒做過三層架構(gòu)的初學者也能照貓畫虎，寫出代碼來。文章表述的是筆者個人對三層架構(gòu)的認識，肯定有許多不足的地方，歡迎大家指正，小弟也會根據(jù)反饋來修改這篇文章。文中的代碼是偽代碼，僅用來闡明思路。

正文：

一提三層架構(gòu)，大家都知道是表現(xiàn)層（UI），業(yè)務邏輯層（BLL）和數(shù)據(jù)訪問層（DAL），而且每層如何細分也都有很多的方法。但具體代碼怎么寫，到底那些文件算在哪一層，卻是模模糊糊的。下面用一個簡單的例子來帶領(lǐng)大家實戰(zhàn)三層架構(gòu)的項目，這個例子只有一個功能，就是用戶的簡單管理。

首先建立一個空白解決方案，添加如下項目及文件

1、添加ASP.NET Web Application項目，命名為UI，新建Web Form類型文件User.aspx（含User.aspx.cs）

2、添加ClassLibrary項目，命名為BLL，新建Class類型文件UserBLL.cs

3、添加ClassLibrary項目，命名為DAL，新建Class類型文件UserDAL.cs。添加SQLHelper引用。（這個是微軟的數(shù)據(jù)訪問類，也可以不用，直接編寫所有的數(shù)據(jù)訪問代碼。我一般用自己寫的數(shù)據(jù)訪問類DataAccessHelper）。

4、添加ClassLibrary項目，命名為Model，新建Class類型文件UserModel.cs

5、添加ClassLibrary項目，命名為IDAL，新建Interface類型文件IUserDAL.cs

6、添加ClassLibrary項目，命名為ClassFactory 相信大家已經(jīng)看出來了，這個和Petshop的示例沒什么區(qū)別，而且更簡單，因為在下也是通過Petshop學習三層架構(gòu)的。但一些朋友對于這幾個項目所處的層次，以及它們之間的關(guān)系，可能比較模糊，這里逐個說明一下：

1、User.aspx和User.aspx.cs 這兩個文件（以及文件所屬的項目，下面也是如此，不再重復強調(diào)了）都屬于表現(xiàn)層部分。User.aspx比較好理解，因為它就是顯示頁面了。User.aspx.cs有些人覺得不應該算，而是要劃到業(yè)務邏輯層中去。如果不做分層的話，那么讓User.aspx.cs來處理業(yè)務邏輯，甚至操作數(shù)據(jù)庫都沒什么問題，但是做分層的話，這樣就不應該了。在分層結(jié)構(gòu)中，User.aspx.cs僅應該處理與顯示有關(guān)的內(nèi)容，其它部分都不應該涉及。

舉例：我們實現(xiàn)用列表方式顯示用戶的功能，那么提取信息的工作是由BLL來做的，UI（本例中是User.aspx.cs）調(diào)用BLL得到UserInfo后，通過代碼綁定到User.aspx的數(shù)據(jù)控件上，就實現(xiàn)了列表的顯示。在此過程中User.aspx.cs對UI沒有起到什么作用，僅是用來傳遞數(shù)據(jù)，而且因為實際編碼中大部分情況都是如此的實現(xiàn)，所以使有些人覺得User.aspx.cs不應該算UI，而應該并入BLL負責邏輯處理。繼續(xù)往下看，這時提出了一個新需求，要求在每個用戶的前面加一個圖標，生動地表現(xiàn)出用戶的性別，而且不滿18歲的用兒童圖標表示。這個需求的實現(xiàn)，就輪到User.aspx.cs來做了，這種情況下User.aspx.cs才算有了真正的用途。

2、NewBLL.cs 添加如下方法：

public IList GetUsers()：返回所有的用戶信息列表

public UserInfo GetUser(int UserId)：返回指定用戶的詳細信息

public bool AddUser(UserInfo User)：新增用戶信息

public bool ChangeUser(UserInfo User)：更新用戶信息

public void RemoveUser(int UserId)：移除用戶信息

此文件就屬于業(yè)務邏輯層了，專門用來處理與業(yè)務邏輯有關(guān)的操作?？赡苡泻芏嗳擞X得這一層唯一的用途，就是把表現(xiàn)層傳過來的數(shù)據(jù)轉(zhuǎn)發(fā)給數(shù)據(jù)層。這種情況確實很多，但這只能說明項目比較簡單，或者項目本身與業(yè)務的關(guān)系結(jié)合的不緊密（比如當前比較流行的MIS），所以造成業(yè)務層無事可做，只起到了一個轉(zhuǎn)發(fā)的作用。但這不代表業(yè)務層可有可無，隨著項目的增大，或者業(yè)務關(guān)系比較多，業(yè)務層就會體現(xiàn)出它的作用來了。

此處最可能造成錯誤的，就是把數(shù)據(jù)操作代碼劃在了業(yè)務邏輯層，而把數(shù)據(jù)庫作為了數(shù)據(jù)訪問層。

舉例：有些朋友感覺BLL層意義不大，只是將DAL的數(shù)據(jù)提上來就轉(zhuǎn)發(fā)給了UI，而未作任何處理?？匆幌逻@個例子

BLL層

SelectUser（UserInfo userInfo）根據(jù)傳入的username或email得到用戶詳細信息。

IsExist（UserInfo userInfo）判斷指定的username或email是否存在。

然后DAL也相應提供方法共BLL調(diào)用

SelectUser（UserInfo userInfo）

IsExist（UserInfo userInfo）這樣BLL確實只起到了一個傳遞的作用。

但如果這樣做：

BLL.IsExist（Userinfo userinfo）

{ UerInfo user = DAL.SelectUser（User）；

return(userInfo.Id!= null);

} 那么DAL就無需實現(xiàn)IsExist()方法了，BLL中也就有了邏輯處理的代碼。

3、UserModel.cs 實體類，這個東西，大家可能覺得不好分層。包括我以前在內(nèi)，是這樣理解的：UI?àModel?àBLL?àModel?àDAL，如此則認為Model在各層之間起到了一個數(shù)據(jù)傳輸?shù)臉蛄鹤饔?。不過在這里，我們不是把事情想簡單，而是想復雜了。

Model是什么？它什么也不是！它在三層架構(gòu)中是可有可無的。它其實就是面向?qū)ο缶幊讨凶罨镜臇|西：類。一個桌子是一個類，一條新聞也是一個類，int、string、doublie等也是類，它僅僅是一個類而已。

這樣，Model在三層架構(gòu)中的位置，和int，string等變量的地位就一樣了，沒有其它的目的，僅用于數(shù)據(jù)的存儲而已，只不過它存儲的是復雜的數(shù)據(jù)。所以如果你的項目中對象都非常簡單，那么不用Model而直接傳遞多個參數(shù)也能做成三層架構(gòu)。

那為什么還要有Model呢，它的好處是什么呢。下面是思考一個問題時想到的，插在這里：

Model在各層參數(shù)傳遞時到底能起到做大的作用？

在各層間傳遞參數(shù)時，可以這樣：

AddUser（userId，userName，userPassword，…，）

也可以這樣：

AddUser（userInfo）

這兩種方法那個好呢。一目了然，肯定是第二種要好很多。

什么時候用普通變量類型（int,string,guid,double）在各層之間傳遞參數(shù)，什么使用Model傳遞？下面幾個方法：

SelectUser（int UserId）

SelectUserByName（string username）

SelectUserByName（string username，string password）

SelectUserByEmail（string email）

SelectUserByEmail（string email，string password）

可以概括為：

SelectUser（userId）

SelectUser（user）

這里用user這個Model對象囊括了username，password，email這三個參數(shù)的四種組合模式。UserId其實也可以合并到user中，但項目中其它BLL都實現(xiàn)了帶有id參數(shù)的接口，所以這里也保留這一項。

傳入了userInfo，那如何處理呢，這個就需要按照先后的順序了，有具體代碼決定。

這里按這個順序處理

首先看是否同時具有username和password，然后看是否同時具有email和password，然后看是否有username，然后看是否有email。依次處理。

這樣，如果以后增加一個新內(nèi)容，會員卡（number），則無需更改接口，只要在DAL的代碼中增加對number的支持就行，然后前臺增加會員卡一項內(nèi)容的表現(xiàn)與處理即可。

4、UserDAL.cs public IList SelectUsers()：返回所有的用戶信息列表

public UserInfo SelectUser(int UserId)：返回指定用戶的相信信息

public bool InsertUser(UserInfo User)：新增用戶信息

public bool UpdateUser(UserInfo User)：更新用戶信息

public void DeleteUser(int UserId)：移除用戶信息

很多人最鬧不清的就是數(shù)據(jù)訪問層，到底那部分才算數(shù)據(jù)訪問層呢？有些認為數(shù)據(jù)庫就是數(shù)據(jù)訪問層，這是對定義沒有搞清楚，DAL是數(shù)據(jù)訪問層而不是數(shù)據(jù)存儲層，因此數(shù)據(jù)庫不可能是這一層的。也有的把SQLHelper（或其同類作用的組件）作為數(shù)據(jù)訪問層，它又是一個可有可無的東西，SQLHelper的作用是減少重復性編碼，提高編碼效率，因此如果我習慣在乎效率或使用一個非數(shù)據(jù)庫的數(shù)據(jù)源時，可以丟棄SQLHelper，一個可以隨意棄置的部分，又怎么能成為三層架構(gòu)中的一層呢。

可以這樣定義：與數(shù)據(jù)源操作有關(guān)的代碼，就應該放在數(shù)據(jù)訪問層中，屬于數(shù)據(jù)訪問層

5、IUserDAL 數(shù)據(jù)訪問層接口，這又是一個可有可無的東西，因為Petshop中帶了它和ClassFactory類工廠，所以有些項目不論需不需要支持多數(shù)據(jù)源，都把這兩個東西做了進來，有的甚至不建ClassFactory而只建了IDAL，然后“IUserDAL iUserDal = new UserDAL();”，不知意義何在。這就完全是畫虎不成反類犬了。

許多人在這里有一個誤解，那就是以為存在這樣的關(guān)系：BLL?àIDAL?àDAL，認為IDAL起到了BLL和DAL之間的橋梁作用，BLL是通過IDAL來調(diào)用DAL的。但實際是即使你如此編碼：“IUserDAL iUserDal = ClassFacotry.CreateUserDAL()；”，那么在執(zhí)行“iUserDal.SelectUsers()”時，其實還是執(zhí)行的UserDAL實例，而不是IUserDAL實例，所以IDAL在三層中的位置是與DAL平級的關(guān)系。

通過上面的介紹，基本上將三層架構(gòu)的層次結(jié)構(gòu)說明了。其實，本人有一個判斷三層架構(gòu)是否標準的方法，那就是將三層中的任意一層完全替換，都不會對其它兩層造成影響，這樣的構(gòu)造基本就符合三層標準了（雖然實現(xiàn)起來比較難^_^）。例如如果將項目從B/S改為C/S（或相反），那么除了UI以外，BLL與DAL都不用改動；或者將SQLServer改為Oracle，只需替換SQLServerDAL到OracleDAL，無需其它操作等等。本來想在文中加入一些具體的代碼的，但感覺不是很必要，如果大家覺得需要的話，我再補充吧。

總結(jié)：不要因為某個層對你來說沒用，或者實現(xiàn)起來特別簡單，就認為它沒有必要，或者摒棄它，或者挪作它用。只要進行了分層，不管是幾層，每一層都要有明確的目的和功能實現(xiàn)，而不要被實際過程所左右，造成同一類文件位于不同層的情況發(fā)生。也不要出現(xiàn)同一層實現(xiàn)了不同的功能的情況發(fā)生。

資料三

三層結(jié)構(gòu)”是“外觀層”、“商業(yè)邏輯層”、“數(shù)據(jù)庫層”

假設以這樣的結(jié)構(gòu)制作一個留言板，那么應該是：

# 留言板頁面的外觀代碼都存放在.aspx 文件中

# 當用戶點擊頁面上的提交按鈕時，先將文本信息傳遞給一個 LeaveWord 類對象（LeaveWord 類的定義被封裝到“商業(yè)邏輯層”）

# 之后讓這個對象執(zhí)行 Post()將留言信息發(fā)送到數(shù)據(jù)庫

用一個簡單的代碼就是：

//---------// 在外觀層，當用戶點擊發(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 插入到表中

} } 這樣，外觀層就不必費心數(shù)據(jù)庫操作了...理解基本正確.但是數(shù)據(jù)層已經(jīng)只是數(shù)據(jù)庫的操作,不應該和業(yè)務有任何關(guān)系,你可以參考SqlHelper.cs 提醒一點,系統(tǒng)的“層”是對代碼的一種邏輯劃分,并不是一定要三層,假設你的系統(tǒng)很簡單,就一個頁面,那一層就可以,如果系統(tǒng)很復雜,也可能是n層.差不離了，核心就是外層絕對不會涉及任何數(shù)據(jù)處理，他的任務是設置界面，獲取數(shù)據(jù)，輸出數(shù)據(jù)

業(yè)務層最重要，所有數(shù)據(jù)處理在這里，如何運用外層提供的數(shù)據(jù)處理業(yè)務 數(shù)據(jù)庫層一般都建議調(diào)用存儲過程，返回數(shù)據(jù)集或其他所需數(shù)據(jù);.net的那兩個例子很好，多學習一下.一個原則： 上層調(diào)下層

上層對下層是不可見的

設計時，表現(xiàn)層只調(diào)用邏輯層，表現(xiàn)層主要是取得頁面的數(shù)據(jù)傳到邏輯層，和把從邏輯層得到的數(shù)據(jù)顯示到頁面上。

邏輯層負責把數(shù)據(jù)加工整理傳到數(shù)據(jù)層和把從數(shù)據(jù)層取得的數(shù)據(jù)加工 數(shù)據(jù)層就只負責把數(shù)據(jù)對數(shù)據(jù)庫操作

業(yè)務邏輯層 就是給上層和下層下達命令和調(diào)節(jié)行為的中間層

資料四：基于組件的三層B/S結(jié)構(gòu)概述

在軟件體系架構(gòu)設計中，分層式結(jié)構(gòu)是最常見，也是最重要的一種結(jié)構(gòu)。微軟推薦的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務邏輯層（又或成為領(lǐng)域?qū)樱?、表示層。三層結(jié)構(gòu)原理

3個層次中，系統(tǒng)主要功能和業(yè)務邏輯都在業(yè)務邏輯層進行處理。

所謂三層體系結(jié)構(gòu)，是在客戶端與數(shù)據(jù)庫之間加入了一個“中間層”，也叫組件層。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結(jié)構(gòu)，也不僅僅有B/S應用才是三層體系結(jié)構(gòu)，三層是指邏輯上的三層，即使這三個層放置到一臺機器上。三層體系的應用程序?qū)I(yè)務規(guī)則、數(shù)據(jù)訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與數(shù)據(jù)庫進行交互，而是通過COM/DCOM通訊與中間層建立連接，再經(jīng)由中間層與數(shù)據(jù)庫進行交互。表示層

位于最外層（最上層），離用戶最近。用于顯示數(shù)據(jù)和接收用戶輸入的數(shù)據(jù)，為用戶提供一種交互式操作的界面 業(yè)務邏輯層

業(yè)務邏輯層（Business Logic Layer）無疑是系統(tǒng)架構(gòu)中體現(xiàn)核心價值的部分。它的關(guān)注點主要集中在業(yè)務規(guī)則的制定、業(yè)務流程的實現(xiàn)等與業(yè)務需求有關(guān)的系統(tǒng)設計，也即是說它是與系統(tǒng)所應對的領(lǐng)域（Domain）邏輯有關(guān)，很多時候，也將業(yè)務邏輯層稱為領(lǐng)域?qū)?。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一書中，將整個架構(gòu)分為三個主要的層：表示層、領(lǐng)域?qū)雍蛿?shù)據(jù)源層。作為領(lǐng)域驅(qū)動設計的先驅(qū)Eric Evans，對業(yè)務邏輯層作了更細致地劃分，細分為應用層與領(lǐng)域?qū)?，通過分層進一步將領(lǐng)域邏輯與領(lǐng)域邏輯的解決方案分離。

業(yè)務邏輯層在體系架構(gòu)中的位置很關(guān)鍵，它處于數(shù)據(jù)訪問層與表示層中間，起到了數(shù)據(jù)交換中承上啟下的作用。由于層是一種弱耦合結(jié)構(gòu)，層與層之間的依賴是向下的，底層對于上層而言是“無知”的，改變上層的設計對于其調(diào)用的底層而言沒有任何影響。如果在分層設計時，遵循了面向接口設計的思想，那么這種向下的依賴也應該是一種弱依賴關(guān)系。因而在不改變接口定義的前提下，理想的分層式架構(gòu)，應該是一個支持可抽取、可替換的“抽屜”式架構(gòu)。正因為如此，業(yè)務邏輯層的設計對于一個支持可擴展的架構(gòu)尤為關(guān)鍵，因為它扮演了兩個不同的角色。對于數(shù)據(jù)訪問層而言，它是調(diào)用者；對于表示層而言，它卻是被調(diào)用者。依賴與被依賴的關(guān)系都糾結(jié)在業(yè)務邏輯層上，如何實現(xiàn)依賴關(guān)系的解耦，則是除了實現(xiàn)業(yè)務邏輯之外留給設計師的任務。數(shù)據(jù)層

數(shù)據(jù)訪問層：有時候也稱為是持久層，其功能主要是負責數(shù)據(jù)庫的訪問，可以訪問數(shù)據(jù)庫系統(tǒng)、二進制文件、文本文檔或是XML文檔。

簡單的說法就是實現(xiàn)對數(shù)據(jù)表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就會包括對象和數(shù)據(jù)表之間的mapping，以及對象實體的持久化。

第三篇：招聘網(wǎng)站優(yōu)劣勢分析

一．土木英才網(wǎng)

土木英才網(wǎng)（http://job.co188.com）是土木在線行業(yè)門戶網(wǎng)站旗下的招聘網(wǎng)站。是專業(yè)為建筑、房地產(chǎn)、工程類企事業(yè)單位以及相關(guān)從業(yè)人員提供招聘、求職的網(wǎng)站。

*土木在線英才網(wǎng)是針對建筑、結(jié)構(gòu)、暖通、制冷、給排水、電氣、園林、水利、環(huán)保、路橋10大行業(yè)企業(yè)的網(wǎng)絡招聘服務平臺，服務范圍輻射全國；

*擁有近1600萬注冊用戶的專業(yè)人才資源庫，80%用戶是設計院所、甲方、施工方和系統(tǒng)集成商等的工程技術(shù)人員；

優(yōu)勢：1600萬土木行業(yè)的用戶，目標用戶準確。由于我們是基于土木在線論壇的招聘網(wǎng)站，用戶在我們平臺的在線時間長。土木在線土木工程行業(yè)用戶必上的網(wǎng)站。是土木工程人員在整個互聯(lián)網(wǎng)最大的學習的家園。人員分布主要以中高端人才為主。中高端人才大多是不會主動求職在這個時候其他幾個招聘網(wǎng)站由于服務內(nèi)容以招聘為主，而我們網(wǎng)站以論壇交流學習為主這時候我們相對其他招聘網(wǎng)站的優(yōu)勢瞬間脫穎而出。

由于每個人對于招聘這東西的需求是短時間內(nèi)的，所以在這個時候土木英才網(wǎng)的優(yōu)勢又出來了，因為在使用土木在線的用戶是長時間的，只要該用戶他需要學習，他就會使用到我們的網(wǎng)站。試想一下，用微軟操作系統(tǒng)的人，有多少人沒用過他的IE瀏覽器呢。當然用戶也會選擇別的瀏覽器。同樣的道理，我們土木在線已經(jīng)提供求職服務了，為什么求職者不去使用了，可能說，求職還會使用別的求職招聘網(wǎng)站，但是在這個時候我們的招聘求職功能會被我們的用戶首先使用。

艾瑞咨詢最新調(diào)研數(shù)據(jù)顯示，2010 年中國網(wǎng)上求職者中，68.7%網(wǎng)上求職者主要集中

在19-30 歲之間。艾瑞咨詢分析認為，大學生和初入職場的白領(lǐng)構(gòu)成了當前中國網(wǎng)上求職者的主力軍。

相對其他的招聘網(wǎng)站來說，我們擁有更多的優(yōu)先展示位，更多的廣告，因為僅僅服務的是土木工程行業(yè)的。而且我們的論壇也提供了我們更多的推薦位。讓我們的會員效果變的更加顯著。而其他幾大招聘網(wǎng)站，廣告位置有限只能通過搜索被求職者檢索到，而其他幾大招聘網(wǎng)站的職位量太大。導致了招聘效果很難顯著。

劣勢：相對其他幾個綜合網(wǎng)站，職位范圍相對專一，廣度不夠，例如中建一局在土木英才網(wǎng)招聘人事這個職位，行政助理，后勤這類職位可能效果不明顯。一般想求職的人，可能不會首先想到我們網(wǎng)站。因為我們不是專門做招聘的。我們的目的就是為了一些土木工程行業(yè)企業(yè)招聘到中高端人才。由于招聘網(wǎng)站按照效果最直接的就是要看企業(yè)有沒有招到想要的人，所以大部分招聘網(wǎng)站最后的競爭主要還是一種品牌的競爭。這也是最致命的，畢竟我們的品牌并不是很強，目前只能用土木在線的品牌來和別的網(wǎng)站來說，而人事很多時候看重的又是土木英才網(wǎng)本身。

二．智聯(lián)招聘

智聯(lián)招聘面向大型公司和快速發(fā)展的中小企業(yè)，提供一站式專業(yè)人力資源服務，包括網(wǎng)絡招聘、校園招聘、獵頭服務、報紙招聘服務、招聘伴侶（RC服務）、企業(yè)培訓以及人才測評等等，并在中國首創(chuàng)了人力資源高端雜志《首席人才官》，是擁有政府頒發(fā)的人才服務許可證和勞務派遣許可證的專業(yè)服務機構(gòu)。

優(yōu)勢：覆蓋的行業(yè)廣，品牌知名度高。

劣勢：中高端人才由于可能不會主動求職，所以在智聯(lián)招聘可能難以招聘到中高端人才。前程無憂由于針對的是所有行業(yè)的所以對于很多的職位很難具體定位，只能讓單位的人事自己來定位這個問題，但很多人事又不懂技術(shù)，所以這就會導致很多職位名稱相互理解出錯，影響招聘效果。當然這個問題，是整個綜合類招聘網(wǎng)站都遇到的問題。由于職位量巨大，如果人事每天不維護三次以上很難達到人事的效果。三．前程無憂

“前程無憂”(Nasdaq: JOBS)是國內(nèi)第一個集多種媒介資源優(yōu)勢的專業(yè)人力資源服務機構(gòu)。它集合了傳統(tǒng)媒體、網(wǎng)絡媒體及先進的信息技術(shù)，加上一支經(jīng)驗豐富的專業(yè)顧問隊伍，提供包括招聘獵頭、培訓測評和人事外包在內(nèi)的全方位專業(yè)人力資源服務，現(xiàn)在全國25個城市設有服務機構(gòu)。

優(yōu)勢：覆蓋的行業(yè)廣，品牌知名度高。

劣勢：中高端人才由于可能不會主動求職，所以在前程無憂可能難以招聘到中高端人才。前程無憂由于針對的是所有行業(yè)的所以對于很多的職位很難具體定位，只能讓單位的人事自己來定位這個問題，但很多人事又不懂技術(shù)，所以這就會導致很多職位名稱相互理解出錯，影響招聘效果。當然這個問題，是整個綜合類招聘網(wǎng)站都遇到的問題。由于職位量巨大，如果人事每天不維護三次以上很難達到人事的效果。

四．58同城

58同城招聘憑借這58同城本身累積大量用戶，由于職位的對外開放所以58同城的職位類別更為豐富。覆蓋的人群更為廣泛。品牌知名度顯著。在互聯(lián)網(wǎng)想到求職的人必定都能想到58同城。

優(yōu)勢：58同城由于在公交車，地鐵等地方的廣告為主要投放地點。58同城擁有大量的中低端人才。

劣勢：中高端人才由于可能不會主動求職，所以在智聯(lián)招聘可能難以招聘到中高端人才。由于58同城門檻較低所以每天的職位量巨大，如果職位不維護可能瞬間會被其他職位所代替，在58同城效果要好就要每天多次維護，以保證更好的效果。

五．建筑英才網(wǎng)

建筑英才網(wǎng)（004km.cn）作為國內(nèi)最權(quán)威最專業(yè)的行業(yè)人才招聘網(wǎng)站--英才網(wǎng)聯(lián)的創(chuàng)始成員，是專業(yè)為建筑設計、工程施工、裝修裝飾、房地產(chǎn)等領(lǐng)域企事業(yè)單位以及相關(guān)從業(yè)人員提供招聘、求職、人才測評、培訓等服務的專業(yè)人才網(wǎng)站。建筑英才網(wǎng)立足于強大的網(wǎng)絡平臺，依靠專業(yè)雜志《建筑英才》和專場招聘會等多渠道的互動資源整合，為泛建筑行業(yè)企業(yè)和求職者構(gòu)建了一套立體式的人力資源服務模式。

經(jīng)過多年的發(fā)展，建筑英才網(wǎng)已成為行業(yè)內(nèi)最具有影響力、專業(yè)性和有效性的人才招聘服務網(wǎng)站。

優(yōu)勢：專業(yè)。具有一定的品牌優(yōu)勢。

劣勢：相對其他幾個綜合網(wǎng)站，職位范圍相對專一，廣度不夠，例如中建一局在土木英才網(wǎng)招聘人事這個職位，行政助理，后勤這類職位可能效果不明顯。由于是垂直類的招聘網(wǎng)站，在品牌知名度這一塊，沒有智聯(lián)招聘58同城響亮，所以很多建筑設計師找工作第一時間可能會想不到建筑英才網(wǎng)。由于招聘網(wǎng)站是短性需求，所以招聘類網(wǎng)站回頭率比較低，而對于建筑英才網(wǎng)要獲得流量來源一方面是品牌效應，大家潛移默化中已經(jīng)知道了，但是這部分用戶占的比率比較少，還有一大部分用戶，還是由于建筑英才網(wǎng)每天鋪天蓋地的廣告。還有就是百度為其帶來的流量。這就導致建筑英才網(wǎng)用戶來源對于廣告的依賴性比較高。

六．地方招聘網(wǎng)（我以常州招聘網(wǎng)為案例）

常州招聘網(wǎng)成立于2007年，由常州同途信息技術(shù)有限公司獨立運營。目前是常州地區(qū)發(fā)展最快，用戶訪問量最高，服務客戶規(guī)模最大的專業(yè)人才招聘網(wǎng)站。我們不斷努力為企業(yè)打造專業(yè)、創(chuàng)新的網(wǎng)絡招聘環(huán)境，為求職者提供尋找工作和職業(yè)發(fā)展的平臺。是常州地區(qū)最具影響力的人力資源網(wǎng)絡服務提供商。招聘、求職，首選常州招聘網(wǎng)。

一直以來，常州招聘網(wǎng)以客戶的使用體驗和使用效果為公司發(fā)展之本，通過我們專業(yè)的客戶服務、完善的網(wǎng)站產(chǎn)品、有效的市場宣傳，打造最具性價比的招聘渠道，幫助客戶以較低的價格、最低的人力成本投入、從最廣泛的選擇范圍，最快地招聘到企業(yè)所需人才。

優(yōu)勢：由于每個地方的人找工作都會首先想到百度地方名后面加上招聘網(wǎng)或者人才網(wǎng)。例如想在常州工作的人，或者人在常州，想工作的人，都會首先百度常州招聘網(wǎng)，或者常州人才網(wǎng)都關(guān)鍵詞。在這個時候當?shù)氐恼衅妇W(wǎng)的優(yōu)勢脫穎而出。當然當?shù)卣衅妇W(wǎng)站要想和別的幾個網(wǎng)站競爭首要條件必須要能夠排在百度第一。數(shù)據(jù)表明用戶點擊排名第一個網(wǎng)站是被點擊率是70%。所以地方上招聘網(wǎng)站排在第一尤為重要。

劣勢：除非當?shù)厝硕贾肋@個網(wǎng)站，否則如果百度排名沒有進入前三可能為企業(yè)帶來的招聘效果就會一塌糊涂。

第四篇：電子商務網(wǎng)站的組織架構(gòu)

B2C電子商務網(wǎng)站的組織架構(gòu)

除了HR和財務部門外，前期電子商務業(yè)務共分為5個部門，包括客服部、市場部、采購及物流部、技術(shù)部和網(wǎng)站運營部。采購和物流其實是可以分開的，在規(guī)模到達一定程度以后，會裂變成采購部和倉儲物流部兩個部門，現(xiàn)在的描述中還是以一個部門說明。

客服部的職能就是客服服務、客戶咨詢、客服培訓和客服考核等，通過各種方式提高用戶滿意度、訂單轉(zhuǎn)化率和平均訂單金額；

技術(shù)部負責網(wǎng)站建設、呼叫中心（Call Center）中心建設、電子商務系統(tǒng)建設、采購系統(tǒng)、倉儲系統(tǒng)、CRM系統(tǒng)以及各種系統(tǒng)之間的對接等；

市場部負責互聯(lián)網(wǎng)和其他媒體推廣、品牌宣傳和公關(guān)、網(wǎng)站合作、支付合作、網(wǎng)站策劃、CRM營銷（會員制分級、EDM營銷、會員合作營銷、數(shù)據(jù)挖掘等）

采購及物流部負責根據(jù)采購名單進行招標和采購，網(wǎng)站倉在全國的布局和設計，制定倉儲標準和物流配送標準，設計倉儲管理系統(tǒng)，選擇物流配送合作伙伴，設計產(chǎn)品配送包裝，根據(jù)訂單的進行配送，并根據(jù)銷售狀況調(diào)節(jié)產(chǎn)品在不同倉儲之間的庫存。

網(wǎng)站運營部負責制定產(chǎn)品定價、策劃并設計產(chǎn)品文案，拍攝并處理產(chǎn)品圖片；負責分析各類型產(chǎn)品，制定采購名單；負責優(yōu)化購物流程，提高用戶的購物體驗；

第五篇：基于.Net三層架構(gòu)高校戶籍管理系統(tǒng)設計與實現(xiàn)

基于.Net三層架構(gòu)高校戶籍管理系統(tǒng)設計與實現(xiàn)

摘 要：為了實現(xiàn)對高校戶籍科學化、規(guī)范化和動態(tài)化管理，提出了一種基于.Net三層架構(gòu)技術(shù)的高校戶籍管理系統(tǒng)解決方案，研究了戶籍管理系統(tǒng)數(shù)據(jù)訪問層、基本邏輯層和頁面表示層的設計及實現(xiàn)。實踐證明了解決方案的有效性。

關(guān)鍵詞：Net；戶籍管理；三層架構(gòu)

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1672-7800（2011）09-0071-02 系統(tǒng)業(yè)務分析??

戶籍管理系統(tǒng)旨在實現(xiàn)對高校戶籍的科學化、規(guī)范化和動態(tài)化管理。通過對戶籍科相關(guān)人員所做需求分析，該系統(tǒng)必須實現(xiàn)以下功能：①戶籍信息管理：包括戶籍基本信息管理，教師和學生戶籍基本信息、相片管理、戶口遷入、遷出、注銷、遷移及借用等信息的增加、刪除和更新；②信息查詢管理：包括戶籍基本信息查詢、學生信息查詢、戶口遷入、遷出、注銷、遷移及借用信息查詢等；③收費管理：學生畢業(yè)之后，學校免費保管學生戶籍兩年，兩年過后按照一定的標準收取保管費用。此模塊主要包括戶籍保管費用的收取和退費等操作；④操作日志管理：戶籍科操作人員的日常工作無法量化，收費操作需要規(guī)范以避免費用的多收、少收、漏收和徇私舞弊的情況的發(fā)生。此模塊將操作人員的所有關(guān)鍵操作記錄在案，以備出現(xiàn)問題時，有據(jù)可查；⑤學院信息管理：此模塊主要包括學生學院和專業(yè)信息的增加、刪除、更新和查詢；⑥系統(tǒng)維護：此模塊用來維護用戶基本信息、管理員的權(quán)限以及數(shù)據(jù)庫的安全，防止非授權(quán)用戶對系統(tǒng)有意或者無意的破壞。??

系統(tǒng)架構(gòu)??

2.1 系統(tǒng)整體架構(gòu)??

分層應用設計當下非常流行。它對系統(tǒng)的性能、可擴展性、可移植性、安全性等提供了有力的保障。經(jīng)典的分層架構(gòu)開發(fā)模式將系統(tǒng)分為3個層次，即數(shù)據(jù)訪問層、基本邏輯層和頁面表示層。當然，每個層次可能分解為更小的子層次以保證系統(tǒng)功能的合理設計。戶籍管理系統(tǒng)的整體架構(gòu)如圖1所示。??

圖1 系統(tǒng)整體架構(gòu)??

2.2 數(shù)據(jù)訪問層設計??

數(shù)據(jù)訪問層負責管理數(shù)據(jù)庫的物理存儲、備份與恢復。主要包括數(shù)據(jù)庫的連接與存取操作，即數(shù)據(jù)庫表的查詢、更新，增加和刪除操作。數(shù)據(jù)訪問層接口對數(shù)據(jù)訪問邏輯進行抽象，以此對不同的數(shù)據(jù)庫（SQL Server，Oracle等）進行統(tǒng)一的管理。通過封裝類調(diào)用數(shù)據(jù)庫的存儲過程，同時，上層基本邏輯層提供統(tǒng)一的調(diào)用接口。??

2.3 基本邏輯層設計??

基本邏輯層作為整個系統(tǒng)的邏輯處理中心，主要負責管理系統(tǒng)的業(yè)務邏輯和規(guī)則。系統(tǒng)的邏輯處理都被抽象為本層的不同的邏輯接口。邏輯層接口處于數(shù)據(jù)訪問層和頁面表示層之間，對上層提供接口調(diào)用，調(diào)用下層數(shù)據(jù)訪問層接口連接數(shù)據(jù)庫，而非直接連接數(shù)據(jù)庫，降低了層與層之間的耦合度。修改數(shù)據(jù)訪問層的接口實現(xiàn)，不需要修改基本邏輯層代碼。??

2.4 頁面表示層設計??

頁面表示層負責接收界面輸入和邏輯結(jié)果的顯示。包括頁面的布局、控件的使用等。頁面表示層調(diào)用基本邏輯層的接口進行邏輯處理。系統(tǒng)邏輯處理發(fā)生變化時，只需要修改基本邏輯層接口實現(xiàn)，不會影響頁面表示層的編碼。??

數(shù)據(jù)庫設計??

好的數(shù)據(jù)庫的設計是信息系統(tǒng)的一個重要組成部分。戶籍管理系統(tǒng)涉及到10多個表的設計和60多個存儲過程的編寫。限于篇幅，這里不一一列出。??

主要技術(shù)及開發(fā)工具??

4.1 權(quán)限管理策略??

系統(tǒng)的訪問控制策略使用基于用戶角色的訪問控制策略。這種訪問控制策略已經(jīng)廣泛應用于系統(tǒng)操作、數(shù)據(jù)庫及應用項目中。角色訪問控制策略有利于確認和管理用戶身份，對不同用戶分配不同的操作權(quán)限。??

4.2 系統(tǒng)安全策略??

為了防止未經(jīng)授權(quán)的用戶訪問系統(tǒng)資源，給系統(tǒng)帶來危害，同時考慮到戶籍管理系統(tǒng)數(shù)據(jù)錄入時間一般集中在開學等時間，大批量的數(shù)據(jù)錄入之后，一旦發(fā)生問題，導致數(shù)據(jù)丟失，再次重復錄入數(shù)據(jù)，工作量巨大。系統(tǒng)使用自動備份與手工備份相結(jié)合的方式，用戶可以通過界面，手工備份與恢復先前的數(shù)據(jù)庫。考慮到數(shù)據(jù)庫的移植，在數(shù)據(jù)訪問層引入“抽象工廠模式”，根據(jù)數(shù)據(jù)庫的不同，提供實現(xiàn)不同數(shù)據(jù)庫結(jié)構(gòu)的數(shù)據(jù)業(yè)務邏輯對象，使用.Net框架的反射機制，在系統(tǒng)運行時動態(tài)決定調(diào)用的數(shù)據(jù)庫類型。??

4.3 并行開發(fā)策略??

三層架構(gòu)的優(yōu)勢之一系統(tǒng)架構(gòu)清晰，合理的分配開發(fā)任務，同時保證系統(tǒng)的并行開發(fā)，以此提高效率。系統(tǒng)開發(fā)過程中，引入實體類和基本邏輯層和數(shù)據(jù)訪問層的共同接口，保證解決方案程序與數(shù)據(jù)庫的并行開發(fā)，兩者相關(guān)部分都完成之后，通過接口，完成數(shù)據(jù)庫庫記錄與實體類的映射即可。??

4.4 版本控制策略??

項目開發(fā)是一個團隊協(xié)作，迭代開發(fā)的過程，版本的控制與管理非常重要。項目開發(fā)過程中使用visual svn和tortoise svn進行系統(tǒng)解決方案、源代碼的控制，單獨設立版本控制服務器，團隊所有成員從服務器中更新項目的最新版本，每天工作完成之后，單獨提交各自負責部分的開發(fā)工作，使服務器中的版本始終保持最新狀態(tài)。??

4.5 項目開發(fā)主要工具??

項目開發(fā)成員使用resharper和coding style enforcer工具保證編碼風格的統(tǒng)一，使用NUnit，NCoverage等工具結(jié)合cruise control.net每日構(gòu)建技術(shù)，進行測試及覆蓋率檢測，保證產(chǎn)品的質(zhì)量。??

結(jié)束語??

戶籍管理系統(tǒng)采用三層架構(gòu)進行設計、開發(fā)，系統(tǒng)接口更加清晰，滿足模塊獨立性，層內(nèi)高內(nèi)聚、層間低耦合的原則，有利于開發(fā)者分工合作，具有很強的通用性、可維護性和可擴展性，可以僅作少量修改升級為Web Service架構(gòu)，為系統(tǒng)維護及功能擴展留下足夠的空間。??

參考文獻：

［1］ HUANG LONGJUN，ZHOU CAIYING，DAI LIPING.Dai Liping.Research and Implementation of E-commerce Platform Based on.NET Framework［Z］.Proceeding of the 2009 International Symposium on Web Information System and Application Nanchang，China，May 22-24,2009.［2］ 陳友良，盛可軍，王陽陽.基于ASP.NET三層架構(gòu)軟件的研究與開發(fā)［J］.現(xiàn)代電子技術(shù)，2010(6).［3］ 江義火.基于ASP.NET MVC2的三層架構(gòu)應用系統(tǒng)開發(fā)研究與實現(xiàn)［J］.軟件導刊，2010(12).（責任編輯：周曉輝）

Design and Implementation of College Residence Management

System Based on.Net and Three-tier Architecture

??

Abstract:In order to realize the scientific，standardized and dynamic management of college Residence booklet , a solution based on.Net and three-tier architecture has been proposed, the design and implementation of data access layer，basic logic layer and presentation layer is discussed.Practice has improved that it is a effective solution.Key Words: Dot Net;Residence Management;Three Tier Architecture