對於三層架構來講,主要是使用設計模式的思想,對於項目的各個模塊實現"高內聚,低耦合"的思想。這裏就不作詳細的介紹了,若是你們有興趣,能夠閱讀軟件工程和設計模式相關文章。mysql
對於三層架構來講,就是使用類,把咱們在作項目的過程當中,可能須要反覆操做數據庫,反覆的使用某個方法等等,可能就是操做的參數不一樣。若是咱們若是在每次使用的時候,都去編寫相應的代碼,無疑會增長程序員的負擔。因此,爲了增長方法的重用,就把這些可以重用的方法抽象成類,以供程序員在其它地方能夠調用。程序員
固然了,這也是面向對象的一部分。其中的三層所指的就是:①視圖層(UI)②數據庫訪問層(DAL)③業務邏輯層(BLL)。固然了,還有所謂的第四層-實體層(model),這一層主要是在這三個層之間進行流動傳遞。可是爲何不叫四層架構。。。緣由我也不知道,多是由於實體層是外在的能夠根據須要會隨時變化的(如:項目後續模塊的添加等)。而其它三個層,若是搭建完後,能夠做爲框架來使用的。。。sql
1)首先仍是先來介紹一下實體層吧,就是咱們一般所說的model數據庫
實體就是咱們在開發項目過程當中所要涉及的一些對象。把這些所要涉及的對象(如:新聞名稱,新聞上傳時間,供稿人,上傳文件的名稱等),都抽象成一個類。使用封裝字段方法,咱們能夠在視圖層通(主要是視圖層)過實例化對象的方法,來給咱們的對象的屬性賦值。設計模式
簡單的看一段代碼吧,可能會可以更加的清楚,明白數組
- public class NewsModel
- {
-
- private int nNewsId;
-
- public int NNewsId
- {
- get { return nNewsId; }
- set { nNewsId = value; }
- }
-
-
- private string strNewsName;
-
- public string StrNewsName
- {
- get { return strNewsName; }
- set { strNewsName = value; }
- }
-
- }
這裏的NewsModel就是一個關於新聞的實體類,其中聲明瞭兩個private的屬性字段(必定要是private,防止非法賦值),使用public的構造函數,能夠在外部給字段賦值。網絡
下面的就是在視圖層來實例化對象,根據須要來給字段賦值,看下面的一段代碼:架構
- <span style="white-space:pre"> </span>NewsModel newModel = new NewsModel();
- newModel.StrNewsName = this.TextBox1.Text;
-
固然了,這僅僅是一段代碼,其中並無給字段nNewsId賦值,由於我把它做爲數據庫的id地段,已經設置成自動增加。這樣,就完成了視圖層對實體層的調用。框架
2)數據庫訪問層函數
數據庫庫訪問層,顧名思義,就是主要來完成對數據庫的訪問,等一系類的對數據庫操做的類。爲何要單獨的把對數據庫的操做抽象成一個單獨的類,我我的理解是由於在整個項目的開發過程當中,不只僅須要一次訪問數據庫,而是須要屢次,若是每次都編寫數據庫訪問代碼的話,會增長程序員的我的工做量,並且對於代碼的易用性和簡潔性來講確定是很是糟糕的。固然來可能還有其它的一些優勢,我暫時尚未發現。
既然是對數據庫的操做類,並且對數據庫的操做,無非就是四種:增刪改查。因此一個能提供增刪改查的通用類是必不可少的。這就是咱們常常所說的,通用數據庫訪問類(不少的程序員都喜歡把這個類命名爲SqlHelper,既然是名字,都是能夠隨意起的,只要不違反C#語法命名規範,固然這樣命名也是有好處,就是可使其餘程序員根據類的名稱,大概判斷出這個類是要幹什麼的)。
固然了,我此次作本身項目的時候,所寫的數據庫訪問類就沒有我上次看周金橋老師的書,而後模仿寫的數據庫訪問類那麼的複雜了(《【ASP.NET開發】ASP.NET對SQLServer的通用數據庫訪問類》)。固然了,我這裏的數據庫訪問類,主要仍是爲了簡介,和易用,只要知足我本身當前項目的須要就能夠了,不是每作一個項目,都要寫一個功能全面的數據庫訪問類。
代碼以下,請你們參考,更喜歡哪一個訪問類,本身能夠根據本身口味,或者須要,直接用也能夠:
- public class SqlHelper
- {
-
- private static readonly string connectionString = ConfigurationManager.ConnectionStrings["strConnectionString"].ConnectionString;
-
-
-
-
-
-
-
- public static int ExecuteNonQuery(string sql, params SqlParameter[] parameters)
- {
- using (SqlConnection con = new SqlConnection(connectionString))
- {
- con.Open();
- using (SqlCommand cmd = con.CreateCommand())
- {
- cmd.CommandText = sql;
- cmd.Parameters.AddRange(parameters);
- string str = sql;
- return cmd.ExecuteNonQuery();
-
- }
- }
- }
-
-
-
-
-
-
-
- public static int ExecuteScalar(string sql, params SqlParameter[] parameters)
- {
- using (SqlConnection con = new SqlConnection(connectionString))
- {
- con.Open();
- using (SqlCommand cmd = con.CreateCommand())
- {
- cmd.CommandText = sql;
- cmd.Parameters.AddRange(parameters);
- return Convert.ToInt32( cmd.ExecuteScalar());
- }
- }
- }
-
-
-
-
-
-
-
- public static DataTable ExecuteDataTable(string sql, params SqlParameter[] parameters)
- {
- using (SqlConnection con = new SqlConnection(connectionString))
- {
- con.Open();
- using (SqlCommand cmd = con.CreateCommand())
- {
- cmd.CommandText = sql;
- cmd.Parameters.AddRange(parameters);
-
- SqlDataAdapter adapter = new SqlDataAdapter(cmd);
- DataTable dt = new DataTable();
- adapter.Fill(dt);
- return dt;
- }
- }
- }
- }
這樣的類建立好之後,其餘的須要訪問數據庫的類,就能夠根據本身的須要,完成相應的增刪改查的操做了。仍是用一段代碼來演示吧:
- public class NewsDALL
- {
-
- public int AddNews(NewsModel model)
- {
- string sql = "insert into News (name,author,time,content,sort,isdelete) values(@name,@author,@time,@content,@sort,@isdelete)";
- int nResult = SqlHelper.ExecuteNonQuery(sql, new SqlParameter("@name", model.StrNewsName), new SqlParameter("@author",model.StrNewsAuthor),new SqlParameter("@time", model.StrAddTime), new SqlParameter("@content", model.StrNewsContent), new SqlParameter("@sort", model.Sort), new SqlParameter("@isdelete", model.IsDelete1));
- return nResult;
- }
-
-
- public int DeleteNew(int id)
- {
- string sql = "delete from News where id=@id";
- int nResult = SqlHelper.ExecuteNonQuery(sql, new SqlParameter("@id", id));
- return nResult;
- }
-
-
- public int UpdateNew(NewsModel model, int nID)
- {
- string sql = "update News set name=@name,time=@time,content=@content where id=" + nID;
- int nResult = SqlHelper.ExecuteNonQuery(sql, new SqlParameter("@name", model.StrNewsName), new SqlParameter("@time", model.StrAddTime), new SqlParameter("@content", model.StrNewsContent));
-
- return nResult;
- }
-
-
- public NewsModel GetNewsModel(int id)
- {
- string sql = "select * from News where id=@id";
- DataTable dt = SqlHelper.ExecuteDataTable(sql, new SqlParameter("@id", id));
-
- if (dt.Rows.Count <= 0)
- {
- return null;
- }
- else if (dt.Rows.Count == 1)
- {
- NewsModel newModel = new NewsModel();
- DataRow dr = dt.Rows[0];
- newModel.StrNewsName = dr["name"].ToString();
- newModel.StrNewsAuthor = dr["author"].ToString();
- newModel.StrAddTime = dr["time"].ToString();
- newModel.StrNewsContent = dr["content"].ToString();
- newModel.Sort = (int)dr["sort"];
-
- return newModel;
- }
- else
- {
- throw new Exception("出現異常!");
- }
- }
- }
這裏的這個NewsDALL類,主要是來完成有關新聞須要對數據庫的各類操做,固然了,這只是這個類的一部分,主要是來演示NewsDALL類怎樣調用SqlHelper類中的方法,來完成對數據庫的操做的。
3)接下來就是最後一層,業務邏輯層了。
業務邏輯層的話主要來處理視圖層和數據庫訪問層之間的關係的。固然了,也能夠直接在視圖層調用數據庫訪問層,可是對於關係來講可能會增長複雜性,因此前輩們就專門的抽象出來一個業務邏輯層,把全部的業務邏輯關係都在這一層處理清楚以後再,訪問數據庫訪問層,進行對數據的操做。(固然這是我本身的理解,若是有什麼不對的話,請你們指正)
在我此次的項目中,貌似個人這一層徹底是多餘的,由於不須要什麼太多的業務邏輯的處理,能夠徹底在視圖層直接訪問數據庫訪問層的。
仍是使用代碼說話吧,固然這個仍然是NewsBLL類代碼的一部分:
- public class NewsBLL
- {
-
- public static int AddNew(NewsModel model)
- {
- NewsDALL newDALL = new NewsDALL();
- return newDALL.AddNews(model);
- }
-
-
- public static int DeleteNew(int i)
- {
- NewsDALL newDALL = new NewsDALL();
- return newDALL.DeleteNew(i);
- }
-
-
-
-
- public static NewsModel GetModel(int intSort)
- {
- NewsModel model = new NewsModel();
- if (intSort == 1)
- {
- model.StrNewSort1 = "學院新聞";
- model.StrNewSort2 = "";
- model.StrNewSort3 = "";
- }
- else if (intSort == 2)
- {
- model.StrNewSort1 = "公告通知";
- model.StrNewSort2 = "";
- model.StrNewSort3 = "";
- }
- ..........
-
- return model;
- }
- }
接下來就是在視圖層來經過訪問,業務邏輯層來和實體層,來玩成所須要的數據操做了。
仍是使用代碼來描述吧,這個代碼主要來完成對數據進行添加:
- public void InsertData()
- {
- NewsModel newModel = new NewsModel();
- newModel.StrNewsName = this.TextBox1.Text;
- newModel.StrNewsAuthor = this.TxtBoxAuthor.Text;
- newModel.StrAddTime = this.TxtDate.Text;
- newModel.StrNewsContent = Server.HtmlDecode(FCKeditor1.Value);
- newModel.Sort =Convert.ToInt32( this.DropDownList2.SelectedValue.ToString());
-
-
- int nResult= NewsBLL.AddNew(newModel);
- if (nResult != 0)
- {
- Response.Write("<script>alert('添加成功!')</script>");
- }
- else
- {
- Response.Write("<script>alert('添加失敗!')</script>");
- }
- }
我之前本身作的圖,被你們指出了不少的錯誤。因此,我就引用了網絡上的一個圖片來解釋(若是侵害了您的版權,請您聯繫我)
![](http://static.javashuo.com/static/loading.gif)
據我本身的理解,三層架構能夠算是一個團隊項目開發的基本框架,在這個框架的基礎上能夠知足一些設計模式的須要。固然能夠知足模塊開發的須要。
總結:
對於我此次的開發項目來講,收穫仍是不少的,之前僅僅是知道有三層架構這個東西,也看書,照着別人的代碼寫過,可是卻不能體會到這其中的真正意義。
優勢:①使代碼的重用更加的高了,不須要像之前作項目,每次在一個頁面反覆的編寫操做數據庫的代碼,而使用三層架構的話,只須要把注意力放在業務邏輯層 的業務邏輯的處理和數據庫訪問層的sql語句的編寫。
②代碼的整潔性,和易用性更加的高了。由於不一樣的操做都分別放在了不一樣的層,因此代碼邏輯更加清晰,若是作好註釋的話,別人可以更加清楚的理解 編寫者的意圖。
③可擴展型更加的高了,根據須要在不一樣的層編寫代碼,而後調用就能夠了。
④很是利於團隊開發。
固然了,三層架構的有點不只僅有這些,否則也不會成爲如今企業開發的基本框架,這只不過是我在開發中明顯的發現的優勢,拿出來跟你們分享一下。
缺點:①就是性能上確定比之前直接在相應的頁面編寫數據庫操做代碼上有點下降。可是這個徹底是能夠接受的,何況,對於我如今的水平就是代碼質量上可定還 有待提升,有更大的優化空間。
②就是在個人項目中,我以爲最大的浪費就是能夠在視圖層直接訪問數據庫訪問層,由於要處理的業務邏輯實在是很少,因此仍是有點代碼冗餘吧。因此, 之後仍是要跟據本身項目的須要,來靈活的使用,不必定要按照規定必須這樣作。