架構（三層架構）、框架（MVC）、設計模式三者異同點

軟體架構  （softwarearchitecture） 

軟體的架構是系統的一個草圖、闡述了各個元件之間的通訊、劃分層次、一旦系統開始詳細設計、架構藍圖就很難甚至無法更改、是由軟體架構師從無到有設計出來的。  

例： 三層架構：一種設計軟體架構的思想  

 把軟體上從邏輯上分為、表示層（UI）業務邏輯層（BLL）資料訪問層（DAL）

目的：低耦合、高內聚、各司其職、達到易更換、修改、可以分散部署、編碼。 

軟體框架（Softwareframework） 

軟體框架是在一定領域內、別人已經對這個領域製作軟體所需的基礎架構功能、進行了總結、做出了有程式碼實體的軟體框架結構、如果要製作這一領域的軟體、可以在別人寫好的框架上、繼續設計、編寫自己的軟體、骨頭架上填肉、框架有一定的侷限性。 

例：MVC（框架）

英文  ModelView Controller、是針對Web開發、已經寫好有程式碼的框架、分別為M 模型(model)－V檢視(view)－C控制器(controller)三部分   

目的：模型和檢視分離開、使得一個模型可被多個檢視使用、簡單說就是同樣的一個網站、用手機的檢視（介面）和電腦的檢視、可以共用一個模型。   

設計模式（Designpattern） 

對軟體設計中普遍存在（反覆出現）的各種問題，所提出的解決方案、是一種解決方案的思想、不拘泥於程式碼、通常以型別或物件來描述其中的關係和相互作用、依賴與抽象、來達到解耦和、可寬展、易維護等、設計模式是用來解決問題的。  

三者區別               

軟體架構是指軟體架構師在製作軟體的時候、對軟體規劃的一種藍圖、一般是分層、畫出各個元件的關係。 

軟體框架是指在特定的領域內、已經有人寫好的框架（有程式碼）、框架有侷限性、只限特定領域。  

設計模式是指標對一些程式設計實際的問題所提出的抽象解決方案、用類與類之間的關係相互作用、達到目的。   

三層架構與MVC的區別 

根本區別是三成是機構而MVC是框架、MVC是應用與Web別人已經寫好的程式碼、如ASP.NET就可以直接點選MVC、會自動生成框架程式碼、而三層是做軟體自己劃分的、是一種製作軟體的思想。

三層架構並不是MVC，MVC是一個很早就有的經典的程式

首先AppCode中，放的是通用類，如資料庫通用類，實現資料庫連線，基本的SqlCommand建立，自定義CRUD的方法等，與三層架構毫無關係，就是常用的開發模式中存放類(Class)的資料夾。

其次，當使用三層架構時，一定是在大專案中，因為三層架構的目的是提高專案的鬆散性和降低專案的耦合度，使之更容易擴充套件或者維護。小專案使用了三層架構，由於過度的在意分層而導致了專案的複雜度增加。

建立三層架構的應用程式。我們必須對這三層分別建立不同的類庫(ClassLibrary)，而不是普通的類(Class)。我們對於任何一個模組或者功能進行OOP，把它擴充套件為物件(面向物件的思想就是：將所操作的目標當成一個物件，對它進行的操作，將由物件自己的方法進行，而非外界傳參。譬如註冊使用者，用面向過程的方法事先，就是:public static bool Register(string userName, string userPwd)。若用OO的思想，我們不可將賬號密碼作為引數傳入，而是將使用者作為一個物件，這個物件具有private _userName，和private _userPwd的屬性。在註冊時，用建構函式初始化一個新的物件，User one = new User(userName,userPwd)，使之在初始化後具有這兩個欄位的值。然後呼叫User類中的public static bool Register()方法(注意這個方法是不進行傳參的)，而在這個Register方法中，使用物件的_userName和_userPwd屬性進行註冊。），那麼，我們在這個物件中的任何操作都將以該物件的方法(函式)實現。

在進行三層分類時，這樣新建類庫。

1.檔案->新建專案->其他專案型別->空白解決方案。

2.在右側的“資源管理器”中，選中當前解決方案，右鍵新增->新建專案->類庫(ClassLibrary)，分別建立BLL,DAL,UL類庫。(若新增後看不到解決方案則在選單->工具->選項->專案和解決方案->總是顯示解決方案)。

3.右鍵，向解決方案中新增一個網站(新網站或者現有網站)。

4.根據需求刪除或者保留預設新增項(預設的class1.cs或Default.aspx檔案)。

這樣一個三層架構的網站雛形就搭建好了。因為UI層要被其他兩層引用，DAL層要被BLL層引用。所以需要相互新增引用，方法是在類庫上點選右鍵->新增引用->專案->選擇其他類庫。並且在具體類中引入名稱空間(using namespace)。

ps：類庫其實就是類的集合，三層架構的目的就是，將同一專案的不同模組都劃分為各自的三層，各司其職，將具體實現方法用類寫出，新增到該層的類庫中，這樣，一個網站下的類庫就只有三層，每一層中都包含了各個模組相對應層的實現方法。在以後修改或擴充套件時，在對應層中進行操作就可以了。

一般的專案，涉及最多的就是對資料庫的CRUD，DAL層只負責與資料庫的互動，BLL層是最重要的一層，他負責將DAL層的的結果呈現給UI層，但是恰恰BLL層的存在似乎有點雞肋，他起到的僅僅是轉發DAL層資料的作用，而具體的邏輯操作是與資料庫的互動，應該寫在DAL層，這就好像BLL層是在重複DAL層的勞動一樣，其實BLL層的作用在於除了呼叫DAL層訪問資料庫，還可以進行邏輯判斷，當符合的時候，才進行允許進行DAL的操作，或者進行額外的操作(如加密，轉換等)。而DAL層可不管這些，他只管進行CRUD的動作。UI層就是操作抽象出來的實體物件，它包含了各種屬性。

一個三層架構的小例子：註冊新使用者。

先寫模組的實體類，是資料庫中表的抽象，假設資料庫中註冊資訊只有賬號，密碼兩個欄位。那麼抽象到實體類就是這樣：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Entity
{
class UserInfo
{
public string UserName { get; set; }    //C#3.0中屬性構造器的新寫法；
public string UserPwd { get; set; }
}
}

再寫DAL層：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using System.Data.SqlClient;
using Entity;   //這裡新增對Entity實體類的引用；
namespace DAL
{
public class UserDAL
{
//在該類中，為了方便，一般會構造一個DataBaseFactory，方便進行程式碼的操作。所以以下程式碼僅為邏輯實現，不代表程式碼正確。
public bool AddUser(UserInfo uInfo) //這裡將實體類作為引數傳入；
{
string sqlStr="INSERT INTO UserInfo(Name,Pwd) VALUES(@name,@pwd)";
SqlCommand cmd=new SqlCommand(sqlStr);
cmd.Parameters.Clear();
cmd.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = uInfo.UserName; //呼叫實體類的屬性
cmd.Parameters.Add("@pwd", SqlDbType.NVarChar, 50).Value = uInfo.UserPwd;
return Convert.ToInt32(cmd.ExecuteNonQuery()) > 0 ？ true : false;
}
public DataTable GetUserInfo(string name)   //根據使用者名稱獲得使用者的具體資訊
{
string sqlStr="SELECT * FROM UserInfo WHERE [email protected]";
SqlCommand cmd=new SqlCommand(sqlStr);
cmd.Parameters.Clear();
cmd.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = name;
SqlDataAdapter sda = new SqlDataAdapter(cmd);
DataSet ds=new DataSet();
sda.Fill(ds,"UserInfo");
return ds.Tables["UserInfo"];
}
}
}

再寫BLL層：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using Entity;   //新增對Entity類庫的引用
using DAL;  //新增對DAL類庫的引用
namespace BLL
{
public class UserBLL
{
public static bool AddUser(UserInfo uInfo)  //BLL層的方法多為靜態方法，DAL層也可以為靜態方法。
{
UserDAL uDal = new UserDAL();
DataTable dTable = uDal.GetUserInfo(uInfo.UserName);
if (dTable.Rows.Count > 0)  //這裡對註冊使用者有一個判斷，從DAL層中先通過註冊名獲得使用者的具體資訊，若可以獲得則證明該使用者名稱已被註冊，返回false；
return false;
else
return uDal.AddUser(uInfo);
}
}
}

最後構建UI層程式碼，即我們的aspx.cs頁面程式碼，該層應該直接呼叫BLL層的方法。該頁面引用BLL和Entity的名稱空間，並向Button控制元件註冊事件：

 protected void btnRegister_OnClick(object sender, EventArgs e)
{
UserInfo uInfo = new UserInfo(textUserName.text, textUserPwd.text);
if (UserBLL.AddUser(uInfo))
Response.Write("註冊成功!");
else
Response.Write("註冊失敗!");
}

這樣一個小的三層架構程式就出來了。

這個程式中，操作的實體為UserInfo表的抽象。在DAL層進行了AddUser()的方法，在BLL層也進行了AddUser()的方法，唯一的區別是BLL層做了邏輯判斷，如果使用者名稱存在，則註冊失敗。

三層架構的特點：

1.資料庫訪問層(DAL)僅提供對資料庫的CRUD（增刪改查）操作，而不管操作後的結果，也不管邏輯過程(譬如同名使用者，不合法使用者名稱)。

2.業務邏輯層(BLL)不會直接與資料庫互動，他與資料庫的互動是通過DAL提供的方法。在呼叫這些方法前，要加入自己的邏輯判斷或者業務處理。另外業務邏輯層(BLL)還有可能不會去呼叫DAL層的方法，而是進行其他業務處理。

3.使用者介面層(UI)層是不會呼叫DAL層的，他只調用BLL層提供的方法，再由BLL層自己決定是否繼續呼叫DAL層。

這個例子可以看出三層架構的優點就是結構清晰，容易擴充套件與維護。缺點就是，複雜，。“三層結構”開發模式，不適用於對執行速度要求過於苛刻的系統。僅僅一個註冊使用者，就這麼麻煩，所以對於小專案來說，費這麼大勁換取一個相對較清晰的分層結構是不划算的。

從開發角度上分析，開發人員可以將應用的商業邏輯放在中間層應用伺服器上，把應用的業務邏輯與使用者介面分開。在保證客戶端功能的前提下，為使用者提供一個簡潔的介面。這意味著如果需要修改應用程式程式碼，只需要對中間層應用伺服器進行修改，而不用修改成千上萬的客戶端應用程式。從而使開發人員可以專注於應用系統核心業務邏輯的分析、設計和開發，簡化了應用系統的開發、更新和升級工作。

理解ASP.NET中的三層結構——為什麼要分三層？我們用三層結構主要是使專案結構更清楚，分工更明確，有利於後期的維護和升級。它未必會提升效能，因為當子程式模組未執行結束時，主程式模組只能處於等待狀態。這說明將應用程式劃分層次，會帶來其執行速度上的一些損失。但從團隊開發效率角度上來講卻可以感受到大不相同的效果。需要說明一下，三層結構不是.NET的專利，也不是專門用在資料庫上的技術。它是一種更加普適的架構設計理念。

如何建立一個三層體系結構解決方案

RL層是邏輯判斷層，主要是對頁面上傳入的資料進行邏輯判斷。

RL層之上就是UI如何建立一個三層體系結構解決方案新建一個空白解決方案。然後：  

“新增”－“新建專案”－“其他專案”－“企業級模版專案”－“C#生成塊”－“資料訪問”（資料層，下簡稱D層）  

“新增”－“新建專案”－“其他專案”－“企業級模版專案”－“C#生成塊”－“業務規則”（業務層，下簡稱C層）

“新增”－“新建專案”－“其他專案”－“企業級模版專案”－“C#生成塊”－“Web使用者介面”（介面層，下簡稱U層）

右鍵點“解決方案”－“專案依賴項”，設定U依賴於D、C，C依賴於D。  

對U新增引用D、C，對C新增引用D。 到此為止，一個三層的架子建立起來了。

特點

“三層結構”開發模式，入門難度夠高，難於理解和學習。這是對於初學程式設計的人來說的。以這種模式開發出來的軟體，程式碼量通常要稍稍多一些。這往往會令初學者淹沒在茫茫的程式碼之中。望之生畏，對其產生反感，也是可以理解的……

其實，無論哪一種開發模式或方法，都是有利有弊的。不會存在一種“萬用法”可以解決任何問題。所以“三層結構”這個詞眼也不會是個例外！是否採用這個模式進行系統開發，要作出比較、權衡之後才可以。切忌濫用!

• 參與資料

1. petshop 4.0的體系結構（只是稍微看了一下，瞭解一下結構）
   
   簡介：PetShop隨著版本的不斷更新，至現在基於.Net 2.0的PetShop4.0為止，整個設計逐漸變得成熟而優雅，而且有很多可以借鑑之處。PetShop是一個小型的專案，系統架構與程式碼都比較簡單，卻也凸現了許多頗有價值的設計與開發理念。 PetShop架構設計
   三層”應用結構：資料訪問層、業務邏輯層（領域層）、表示層
   分層的設計的特點：
   結構清晰、耦合度低
   便於系統的擴充套件
   利於開發任務同步進行
   降低了一定的效能