㈠ c#利用三層架構寫分頁查詢價的簡單實例
首先還是簡單的提一下 三層架構吧：
1、表現層（UI）：通俗講就是展現給用戶的界面，即用戶在使用一個系統的時候他的所見所得。
2、業務邏輯層（BLL）：針對具體問題的操作，也可以說是譽賣對數據層的操作，對數據業務邏輯處理。
3、數據訪問層（DAL）：該層所做事務直接操作資料庫，針對數據的增添、刪除、修改、更新、查找等。
下面就介紹一下 範例的 步驟：
1.打開VS2008後，文件-->新建-->項目-->其他項目類型-->Visual Studio 解決方案-->空白解決方案 就起名為:MvcTest 吧
2.建立
的項目,並在WEB-->App_Data建一個數據文件 DabaBase.mdf 裡面建表:qzzm_user 表內:欄位Name,類型:nvarchar(50) 非空
3.在WEB中引用BLL,Model層新建Post.aspx
Post.aspx 代碼如下：睜冊
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Post.aspx.cs" Inherits="Post" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>無標題頁</title>
</head>
<body>
<form id="form1" runat="server">
<div>慶早逗
<asp:TextBox ID="tb_name" runat="server"></asp:TextBox>
<asp:Button ID="btn_post" runat="server" OnClick="btn_post_Click" Text="提交" />
</div>
</form>
</body>
</html>
Post.aspx.cs 先擱下等寫好類庫再寫
4.在Model 實體類中新建一個user.cs的類 （如果你已經按照上面的圖 將類都建好了 就只用看下面的代碼就好了）
user.cs代碼如下：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Model
{
public class user
{
public user() { }
private string _Name;
public string Name
{
set { _Name = value; }
get { return _Name; }
}
}
}
5.在DAL新建userdb.cs,並引用Model層 （滑鼠右鍵——添加引用——項目 選擇所需的引用）
userdb.cs代碼如下：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.sqlClient;
using System.Configuration;
namespace DAL
{
public class userdb
{
public bool adser(Model.user model)
{
SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["sqlconn"].ConnectionString);//此行@
con.Open();
using (SqlCommand cmd = new SqlCommand("INSERT INTO qzzm_user(Name) VALUES(@Name)", con))
{
cmd.Parameters.AddWithValue("@Name", model.Name);
if (cmd.ExecuteNonQuery() > 0)
return true;
else return false;
}
}
}
}
代碼寫好了還不行，因為到時候調試的時候可能會出現 「當前上下文中不存在名稱「ConfigurationManager」 」（注釋 所在行），出現這種錯誤的原因是沒有引用System.Configuration 這項，注意這邊可不是代碼中的 using System.Configuration; 哦。此時就要添加System.Configuration的引用，方法同上面的引用Model層類似，在DAL層下 右鍵——添加引用——.NET 然後找到對應的 System.Configuration 確定即可。
（如果沒出現上面所說的問題當然是最好咯 O(∩_∩)O~）
6.在BLL中新建userbll.cs並引用DAL,Model層
userbll.cs代碼如下：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace BLL
{
public class userbll
{
DAL.userdb db = new DAL.userdb();
public bool adser(Model .user model)
{
return db.adser(model);
}
}
}
7.開始寫Post.aspx.cs
代碼如下：
using System;
using System.Collections;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
public partial class Post : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void btn_post_Click(object sender, EventArgs e)
{
Model.user us = new Model.user();
us.Name = tb_name.Text;
BLL.userbll ub = new BLL.userbll();
ub.adser(us );
}
}
8.在Web.config文件中添加 缺少的數據鏈接字元串
找到<connectionStrings /> 這一行，將其修改如下：
<connectionStrings>
<add name="sqlconn" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\Database.mdf;Integrated Security=True;User Instance=True" providerName="System.Data.SqlClient" />
</connectionStrings>
9. 調試 執行
此時會提示 「無法直接啟動帶有……」的信息
此時我們只要找到 Post.aspx 右鍵——在瀏覽器中查看 即可 。 輸入數據——提交 ，即可到所建的資料庫中找到所輸入的數據。
一個簡單的三層架構例子 到此完成。
各層引用關系如下：
1) WEB引用 DAL,Model
2)BLL引用 DAL,Model
3)DAL引用Model （以及解決錯誤時 引用的System.Configuration ）
4)Model無引用
㈡ 在Javaweb中如何體現三層架構思想
一個非常好的問題。三層或者多層架構的核心思想是分層，不同粒度和維度都有應用。
一，系統架構
常見的動靜分離、數據中台、微服務在一定程度上都是將系統實現進行分層解耦，從而使頃游空得系統表現為不同的層次，比如典型的前端頁面展示、介面服務、數據存儲。
二，前端架構
以典型的AntDesign開發信息管理系統為例，將前端實現分為Page、Model、Service三層，Page展示頁面響應用戶操作，Model保雀瞎存數據，Service處理業務邏輯、調用後台服務介面。
三，後磨坦端架構
在後端開發中，仍然會採用分層架構。比如常用的Java+SpringBoot框架開發Web服務時，有Controller，Service，Entity，分別封裝
我是工作多年的Web應用架構師，歡迎在線咨詢
㈢ 昌平電腦培訓分享三層架構實現JavaWeb案例
三層架構一方面是為了解決應用程序中代碼之間調用復雜，代碼職責不清的問題;通過各層之間定義介面的形式，並將介面與實現分離，可以很容易的用不同的實現來替換原有的實現，從而有效的降低層與層之間的依賴關系。這種方式不僅有利於整個團隊理解整個應用架構，降低後期維護成本，同時也有利於制定整個應用程序架構的標准。
另一方面三層架構的出現從某種程度上解決了企業內部如果有效的根據技能調配技術人員，提高生產效率的問題，在大環境下，有效的分層能使不同職責的人各司其職，聚焦於個人專業技能的發展與培養上。
三層架構的出現不僅標准化了復雜系統的邏輯劃分，更幫助企業解決如果有效的形成技術人員組織機構的問題，因此在很長的一段時間內，它一直是軟體架構設計的經典模式之一。
優勢
層次清晰，每個層次都提供了介面定義
很容易用新的實現替換原來的層次實現。例如對sql進行性能優化，並不會影響其他層的代碼結構。有利於後期維護。
有利於實現切面編程，減輕業務的復雜程度，加快編碼效率。
每個層正滑悔次的定位明晰，業務處理的內容明確。依據層次，可以劃分不同的分工。開發人員可以只關注整個結構的其中某一層。
介面定義也提供了良好讓悶的可擴展性。例如資料庫從mysql切換到oracle，只需要通過配置來切換。
降低了代碼之間，層與層的依賴關系
復用性：利於各層代碼邏輯的復用
安全性：介面設計需要符合對擴展開發，對修改關閉的原則，增強了系統的安全性
各層次職責
表示層：是應用的用戶介面部分，擔負著用戶與應用的對話，交互功能。
業務邏輯層：主要是業務邏輯的處理，操作，是系統功能核心。
數據訪問層：也稱為是數據持久層，昌平電腦培訓發現其功能主要是負責數舉正據庫的訪問。
㈣ Java Web 開發時的 MVC 模型和軟體的3層架構(表現層，業務邏輯層，數據訪問層)有哪些區別和聯系
三層架構和MVC是有明顯區別的,MVC應該是展現模式(三個加起來以後才是三層架構中的UI層)
三層架構(3-tier application) 通常意義上的三層架構就是將整個業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。區分層次的目的即為了「高內聚，低耦合」的思想。
1、表現層（UI）：通俗講就是展現給用戶的界面，即用戶在使用一個系統的時候他的所見所得。
2、業務邏輯層（BLL）：針對具體問題的操作，也可以說是對數據層的操作，對數據業務邏輯處理。
3、數據訪問層（DAL）：該層所做事務直接操作資料庫，針對數據的增添、刪除、修改、更新、查找等。
MVC是 Model-View-Controller，嚴格說這三個加起來以後才是三層架構中的UI層，也就是說，MVC把三層架構中的UI層再度進行了分化，分成了控制器、視圖、實體三個部分，控制器完成頁面邏輯，通過實體來與界面層完成通話；而C層直接與三層中的BLL進行對話。
㈤ 什麼是jsp web三層架構
三層架構(3-tier architecture) 通常意義上的三層架構就是將整個業務應用劃分為：界面層（User Interface layer）、業務邏輯層（Business Logic Layer）、數據訪問層（Data access layer）。區分層次的目的即為了「高內聚低耦合」的思想。在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：數據訪問層（又稱為持久層）、業務邏輯層（又或稱為領域層）、表示層。
表示層（UI層）:
表示層也稱為界面層，位於最外層（最上層），離用戶最近。用於顯示數據和接收用戶輸入的數據，為用戶提供一種互動式操作的界面。
業務邏輯層（BLL層）:
負責關鍵業務的處理和數據的傳遞。復雜的邏輯判斷和涉及到資料庫的數據驗證都需要在此做出處理。主要是針對具體的問題的操作，也可以理解成對數據層的操作，對數據業務邏輯處理，如果說數據層是積木，那邏輯層就是對這些積木的搭建。
數據訪問層（DAL層）：
主要負責對資料庫的直接訪問，為業務邏輯層提供數據，根據傳入的值來操作資料庫，增、刪、改、查。
㈥ 什麼是三層架構各層的主要功能及相互關系有哪些
一般講到三層架構，其實就是將整個業務應用劃分為表示層、業務邏輯層、數據訪問層等。
數據訪問層DAL，業務邏輯層BLL。表現層UI （界面類的）【 model（數據模型層，主要放的我就不用說了。一般都是資料庫中的。） ，】model是貫穿的。所有的都引用它，bll引用dal ui引用dal 和bll 然後就是調用
三層體系結構，是在客戶端與資料庫之間加入了一個「中間層」，也叫組件層。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三台機器就是三層體系結構，也不僅僅有B/S應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一台機器上。
普通三層：數據訪問層DAL：用於實現與資料庫的交互和訪問，從資料庫獲取數據或保存數據到資料庫的部分。 業務邏輯層BLL：業務邏輯層承上啟下，用於對上下交互的數據進行邏輯處理，實現業務目標。 表示層UI：主要實現和用戶的交互，接收用戶請求或返回用戶請求的數據結果的展現，而具體的數據處理則交給業務邏輯層和數據訪問層去處理。業務實體Model：用於封裝實體類數據結構，一般用於映射資料庫的數據表或視圖，用以描述業務中客觀存在的對象。Model分離出來是為了更好地解耦，為了更好地發揮分層的作用，更好地進行復用和擴展，增強靈活性。 通用類庫Common：通用的輔助工具類
工程模式：簡單工廠模式又稱為靜態工廠方法（Static Factory Method）模式，屬於類的創建型模式，通常根據一個條件（參數）來返回不同的類的實例。
工廠角色（Creator）
是簡單工廠模式的核心，它負責實現創建所有具體產品類的實例。工廠類可以被外界直接調用，創建所需的產品對象。
抽象產品角色（Proct）
是所有具體產品角色的父類，它負責描述所有實例所共有的公共介面。
具體產品角色（Concrete Proct）
繼承自抽象產品角色，一般為多個，是簡單工廠模式的創建目標。工廠類返回的都是該角色的某一具體產品。
通常情況下，客戶端不直接與資料庫進行交互，而是通過COM/DCOM通 訊與中間層建立連接，再經由中間層與資料庫進行交換.
完善的三層結構的要求是:修改表現層而不用修改邏輯層,修改邏輯層而不用修改數據層 否則你的應用是不是多層結構,或者說是層結構的劃分和組織上是不是有問題就很難說. 不同的應用有不同的理解，這是一個概念的問題．
MVC系統中的模型從概念上可以分為兩類――系統的內部狀態和改變系統狀態的動作。模型是你所有的商業邏輯代碼片段所在。本文為模型提供了業務實體對象和業務處理對象：所有的業務處理對象都是從ProcessBase類派生的子類。業務處理對象封裝了具體的處理邏輯，調用業務邏輯模型，並且把響應提交到合適的視圖組件以產生響應。業務實體對象可以通過定義屬性描述客戶端表單數據。所有業務實體對象都EntityBase派生子類對象，業務處理對象可以直接對它進行讀寫，而不再需要和request、response對象進行數據交互。通過業務實體對象實現了對視圖和模型之間交互的支持。實現時把"做什麼"（業務處理）和"如何做"（業務實體）分離。這樣可以實現業務邏輯的重用。由於各個應用的具體業務是不同的，這里不再列舉其具體代碼實例。
MVC（模型Model-視圖View-控制器Controller）是一種設計模式，我們可以用它來創建在域對象和UI表示層對象之間的區分。 同樣是架構級別的，相同的地方在於他們都有一個表現層，但是他們不同的地方在於其他的兩個層。 在三層架構中沒有定義Controller的概念。這是我認為最不同的地方。而MVC也沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程序最主要的區別。當然了。在三層中也提到了Model，但是三層架構中Model的概念與MVC中Model的概念是不一樣的，「三層」中典型的Model層是以實體類構成的，而MVC里，則是由業務邏輯與訪問數據組成的。
在ASP NET中的MVC架構編寫的，具有極其良好的可擴展性。它可以輕松實現以下功能： ①實現一個模型的多個視圖；②採用多個控制器；③當模型改變時，所有視圖將自動刷新；④所有的控制器將相互獨立工作。這就是MVC架構的好處，只需在以前的程序上稍作修改或增加新的類，即可輕松增加許多程序功能。以前開發的許多類可以重用，而程序結構根本不再需要改變，各類之間相互獨立，便於團體開發，提高開發效率。下面討論如何實現一個模型、兩個視圖和一個控制器的程序。其中模型類及視圖類根本不需要改變，與前面的完全一樣，這就是面向對象編程的好處。對於控制器中的類，只需要增加另一個視圖，並與模型發生關聯即可。該模式下視圖、控制器、模型三者之間的示意圖如圖2所示。同樣也可以實現其它形式的MVC例如：一個模型、兩個視圖和兩個控制器。從上面可以看出，通過MVC架構實現的應用程序具有極其良好的可擴展性，是ASP NET面向對象編程的未來方向。
MVC的不足體現在以下幾個方面：（1）增加了系統結構和實現的復雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的復雜性，並可能產生過多的更新操作，降低運行效率。（2）視圖與控制器間的過於緊密的連接。視圖與控制器是相互分離，但確實聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。3）視圖對模型數據的低效率訪問。依據模型操作介面的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。（4）目前，一般高級的界面工具或構造器不支持MVC架構。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的困難。
三層架構是將代碼按其作用分成三部分,每部分解決自己負責的流程. 三層架構的功用之處,在於駕馭大型web程序的結構,使之便於管理和擴展.
在設計UI的時候,我們不需要關心其中的邏輯和數據問題,只需要空出對應的位置,用於放置數據. 在設計和修改的時候,要解決的只是HTML的結構,代碼看起來干凈利落,做起來也是干凈利落.
UI直接將程序邏輯的任務丟給BLL,BLL就開始構建具體的實現細節.BLL的創建依賴於業務. 例如一個文章系統,BLL_Aticle就表示它是用於對文章的處理的.BLL_Aticle可以提供給UI一個文章列表的recordset,顯示在UI的預留位置. 當BLL_Aticle需要從資料庫中獲取數據的時候,就將任務丟給DAL層
DAL層專門負責和資料庫打交道,它從BLL獲取參數,組織一個有效的SQL,建立資料庫連接,執行SQL進行更新或獲取,將返回的數據交給BLL.
每一部分的業務都集中於一個UI-BLL-DAL的鏈中,上下清晰瞭然. 至於是怎樣的便於管理和擴展,將在後面結合實例進行分析.
復雜的生命形式必有復雜的生存法則,若想在自己的項目中應用好三層架構,需要多用點心體會其中的應用法則.
我對三層架構的理解還不夠深,這些文章能算是拋磚引玉就不錯了.大家在閱讀當中不要局限於我所構思的法則,要多向具體的應用中去實踐,根據具體情況,尋出自己的法則. 有所感悟,就記得寫下來,這種感悟是進步的契機,但必然不是最終的結果.有了感悟就拿去應用,可以發現它的優劣,繼續完善
三層架構比雙層或單層結構都有更大的優勢。三層結構適合群體開發，每人可以有不同的分工，協同工作使效率倍增。開發雙層或單層應用時，每個開發人員都應對系統有較深的理解，能力要求很高，開發三層應用時，則可以結合多方面的人才，只需少數人對系統全面了解，從一定程度工降低了開發的難度。
三層架構屬於瘦客戶的模式，用戶端只需一個較小的硬碟、較小的內存、較慢的CPU就可以獲得不錯的性能。相比之下，單層或胖客戶對面器的要求太高。
三層架構的另一個優點在於可以更好的支持分布式計算環境。邏輯層的應用程序可以有多個機器上運行，充分利用網路的計算功能。分布式計算的潛力巨大，遠比升級CPU有效。
三層架構的最大優點是它的安全性。用戶端只能通過邏輯層來訪問數據層，減少了入口點，把很多危險的系統功能都屏蔽了。
㈦ 求一張網路三層架構的圖
三層網路架構是採用層次化架構的三層網路。
三層網路架構設計的網路有三個層次：核心層（網路的高速交換主幹）、匯聚層（提供基於策略的連接）、接入層 （將工作站接入網路）。
(7)web三層架構實例擴展閱讀：
三層網路結構短板
1、不斷地改變的三層網路結構數據中心網路傳輸模式。
2、網路收斂：三層網路結構中，同一個物理網路中的儲存網路和通信網路，主機和陣列之間的數據傳輸通過儲存網路來傳輸，在邏輯拓撲上就像是直接連接的一樣
3、虛擬化：將物理客戶端向虛擬客戶端轉化，虛擬化伺服器是未來發展的主流和趨勢，它使得三層網路結構的網路節點的移動變得非常簡單。
4、如果三層網路結構上主機需要通過高速帶寬相互訪問，但通過層層的uplink口，會導致潛在的、而且非常明顯的性能衰減。三層網路結構的原始設計更會加劇這種性能衰減，由於生成樹協議會防止冗餘鏈路存在環路，雙上行鏈路接入交換機只能使用一個指定的網路介面鏈接。
5、橫向網路（east-west）在縱向設計的三層網路結構中傳輸數據會帶有傳輸的瓶頸，因為數據經過了許多不必要的節點（如路由和交換機等設備）。
㈧ 深入淺出C#三層架構
本文用一個示例來介紹如何建設一個三層架構的項目 並說明項目中各個文件所處的層次與作用 寫本文的目的 不是為了說明自己的這個方法有多薯讓高對 而是希望給那些初學三層架構卻不知從何入手的朋友提供一點幫助 因為網上的文章 大多是注重理論的介紹 而忽略了具體的實踐應用 或者有示例但講得不透徹 導致看了之後 理論上又滑帆學習了一遍 但還是不知道代碼怎麼寫 所以想從這個方面入手寫一下 讓從來沒做過三層架構的初學者也能照貓畫虎 寫出代碼來 文中的代碼是偽代碼 僅用來闡明思路
正文
一提三層架構 大家都知道是表現層（UI） 業務邏輯層（BLL）和數據訪問層（DAL） 而且每層如何細分也都有很多的方法 但具體代碼怎麼寫 到底那些文件算在哪一層 卻是模模糊糊的 下面用一個簡單的例子來帶領大家實戰三層架構的項目 這個例子只有一個功能 就是用戶的簡單管理
首先建立一個空白解決方案 添加如下項目及文件
添加ASP NET Web Application項目 命名為UI 新建Web Form類型文件User aspx（含User aspx cs）
添加ClassLibrary項目 命名為BLL 新建Class類型文件UserBLL cs
添加ClassLibrary項目 命名為DAL 新建Class類型文件UserDAL cs 添加SQLHelper引用 （這個是微軟的數據訪問類 也可以不用 直接編寫所有的數據訪問代碼 我一般用自己寫的數據訪問類DataAccessHelper ）
添加ClassLibrary項目 命名為Model 新建Class類型文件UserModel cs
添加ClassLibrary項目 命名為IDAL 新建Interface類型文件IUserDAL cs
添加ClassLibrary項目 命名為ClassFactory
相信大家已經看出來了 這個和Petshop的示例沒什麼區別 而且更簡單 因為在下也是通過Petshop學習三層架構的 但一些朋友對於這幾個項目所處的層次 以及它們之間的關系 可能比較模糊 這里逐個說明一下
User aspx和User aspx cs
這兩個文件（以及文件所屬的項目 下面也是如此 不再重復強調了）都屬於表現層部分 User aspx比較好理解 因為它就是顯示頁面了 User aspx cs有些人覺得不應該算 而是要劃到業務邏輯層中去 如果不做分層的話 那麼讓User aspx cs來處理業務邏輯 甚至操作資料庫都沒什麼問題 但是做分層的話 這樣就不應該了 在分層結構中 User aspx cs僅應該處理與顯示有關的內容 其它部分都不應該涉及
舉例 我們實現用列表方式顯示用戶的功能 那麼提取信息的工作是由BLL來做的 UI（本例中是User aspx cs）調用BLL得到UserInfo後 通過代碼綁定到User aspx的數據控制項上 就實現了列表的顯示 在數尺此過程中User aspx cs對UI沒有起到什麼作用 僅是用來傳遞數據 而且因為實際編碼中大部分情況都是如此的實現 所以使有些人覺得User aspx cs不應該算UI 而應該並入BLL負責邏輯處理 繼續往下看 這時提出了一個新需求 要求在每個用戶的前面加一個圖標 生動地表現出用戶的性別 而且不滿 歲的用兒童圖標表示 這個需求的實現 就輪到User aspx cs來做了 這種情況下User aspx cs才算有了真正的用途
NewBLL cs
添加如下方法
public IList<UserInfo> GetUsers（） 返回所有的用戶信息列表
public UserInfo GetUser（int UserId） 返回指定用戶的詳細信息
public bool AddUser（UserInfo User） 新增用戶信息
public bool ChangeUser（UserInfo User） 更新用戶信息
public void RemoveUser（int UserId） 移除用戶信息
此文件就屬於業務邏輯層了 專門用來處理與業務邏輯有關的操作 可能有很多人覺得這一層唯一的用途 就是把表現層傳過來的數據轉發給數據層 這種情況確實很多 但這只能說明項目比較簡單 或者項目本身與業務的關系結合的不緊密（比如當前比較流行的MIS） 所以造成業務層無事可做 只起到了一個轉發的作用 但這不代表業務層可有可無 隨著項目的增大 或者業務關系比較多 業務層就會體現出它的作用來了
此處最可能造成錯誤的 就是把數據操作代碼劃在了業務邏輯層 而把資料庫作為了數據訪問層
舉例 有些朋友感覺BLL層意義不大 只是將DAL的數據提上來就轉發給了UI 而未作任何處理 看一下這個例子
BLL層
SelectUser（UserInfo userInfo）根據傳入的username或email得到用戶詳細信息
IsExist（UserInfo userInfo）判斷指定的username或email是否存在
然後DAL也相應提供方法共BLL調用
SelectUser（UserInfo userInfo）
IsExist（UserInfo userInfo）
這樣BLL確實只起到了一個傳遞的作用
但如果這樣做
BLL IsExist（Userinfo userinfo）
{
UerInfo user = DAL SelectUser（User）
return （userInfo Id != null）
}
那麼DAL就無需實現IsExist（）方法了 BLL中也就有了邏輯處理的代碼
UserModel cs
實體類 這個東西 大家可能覺得不好分層 包括我以前在內 是這樣理解的 UI?àModel?àBLL?àModel?àDAL 如此則認為Model在各層之間起到了一個數據傳輸的橋梁作用 不過在這里 我們不是把事情想簡單 而是想復雜了
Model是什麼？它什麼也不是！它在三層架構中是可有可無的 它其實就是面向對象編程中最基本的東西 類 一個桌子是一個類 一條新聞也是一個類 int string doublie等也是類 它僅僅是一個類而已
這樣 Model在三層架構中的位置 和int string等變數的地位就一樣了 沒有其它的目的 僅用於數據的存儲而已 只不過它存儲的是復雜的數據 所以如果你的項目中對象都非常簡單 那麼不用Model而直接傳遞多個參數也能做成三層架構
那為什麼還要有Model呢 它的好處是什麼呢 下面是思考一個問題時想到的 插在這里
Model在各層參數傳遞時到底能起到做大的作用？
在各層間傳遞參數時 可以這樣
AddUser（userId userName userPassword … ）
也可以這樣
AddUser（userInfo）
這兩種方法那個好呢 一目瞭然 肯定是第二種要好很多
什麼時候用普通變數類型（int string guid double）在各層之間傳遞參數 什麼使用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這三個參數的四種組合模式 UserId其實也可以合並到user中 但項目中其它BLL都實現了帶有id參數的介面 所以這里也保留這一項
傳入了userInfo 那如何處理呢 這個就需要按照先後的順序了 有具體代碼決定
這里按這個順序處理
首先看是否同時具有username和password 然後看是否同時具有email和password 然後看是否有username 然後看是否有email 依次處理
這樣 如果以後增加一個新內容 會員卡（number） 則無需更改介面 只要在DAL的代碼中增加對number的支持就行 然後前台增加會員卡一項內容的表現與處理即可
UserDAL cs
public IList<UserInfo> SelectUsers（） 返回所有的用戶信息列表
public UserInfo SelectUser（int UserId） 返回指定用戶的相信信息
public bool InsertUser（UserInfo User） 新增用戶信息
public bool UpdateUser（UserInfo User） 更新用戶信息
public void DeleteUser（int UserId） 移除用戶信息
很多人最鬧不清的就是數據訪問層 到底那部分才算數據訪問層呢？有些認為資料庫就是數據訪問層 這是對定義沒有搞清楚 DAL是數據訪問層而不是數據存儲層 因此資料庫不可能是這一層的 也有的把SQLHelper（或其同類作用的組件）作為數據訪問層 它又是一個可有可無的東西 SQLHelper的作用是減少重復性編碼 提高編碼效率 因此如果我習慣在乎效率或使用一個非資料庫的數據源時 可以丟棄SQLHelper 一個可以隨意棄置的部分 又怎麼能成為三層架構中的一層呢
可以這樣定義 與數據源操作有關的代碼 就應該放在數據訪問層中 屬於數據訪問層
IUserDAL
數據訪問層介面 這又是一個可有可無的東西 因為Petshop中帶了它和ClassFactory類工廠 所以有些項目不論需不需要支持多數據源 都把這兩個東西做了進來 有的甚至不建ClassFactory而只建了IDAL 然後 IUserDAL iUserDal = new UserDAL（） 不知意義何在 這就完全是畫虎不成反類犬了
許多人在這里有一個誤解 那就是以為存在這樣的關系 BLL?àIDAL?àDAL 認為IDAL起到了BLL和DAL之間的橋梁作用 BLL是通過IDAL來調用DAL的 但實際是即使你如此編碼 IUserDAL iUserDal = ClassFacotry CreateUserDAL（） 那麼在執行 iUserDal SelectUsers（） 時 其實還是執行的UserDAL實例 而不是IUserDAL實例 所以IDAL在三層中的位置是與DAL平級的關系
通過上面的介紹 基本上將三層架構的層次結構說明了 其實 本人有一個判斷三層架構是否標準的方法 那就是將三層中的任意一層完全替換 都不會對其它兩層造成影響 這樣的構造基本就符合三層標准了（雖然實現起來比較難^_^） 例如如果將項目從B/S改為C/S（或相反） 那麼除了UI以外 BLL與DAL都不用改動 或者將SQLServer改為Oracle 只需替換SQLServerDAL到OracleDAL 無需其它操作等等 本來想在文中加入一些具體的代碼的 但感覺不是很必要 如果大家覺得需要的話 我再補充吧
lishixin/Article/program/net/201311/11365
㈨ ASp.net 剖析三層架構
本文不是從理論的角度來探討三層架構，而是用一個示例來介紹如何建設一個三層架構的項目，並說明項目中各個文件所處的層次與作用。寫本文的目的，不是為了說明自己的這個方法有多對，別人的肯定不對，而是希望給那些初學三層架構卻不知從何入手的朋友提供一點幫助。因為網上的文章，大多是注重理論的介紹，而忽略了具體的實踐應用，或者有示例但講得不透徹。導致看了之後，理論上又學習了一遍，但還是不知道代碼怎麼寫。所以想從這個方面入手寫一下晌如，讓從來沒做過三層架構的初學者也能照貓畫虎，寫出代碼來。文章表述的是筆者個人對三層架構的認識，肯定有許多不足的地方，歡迎大家指正，小弟也會根據反饋來修改這篇文章。文中的代碼是偽代碼，僅用來闡明思路。
一提三層行滑架構，大家都知道是表現層（UI），業務邏輯層（BLL）和數據訪問層（DAL），而且每層如何細分也都有很多的方法。但具體代碼怎麼寫，到底那些文件算在哪一層，卻是模模糊糊的。下面用一個簡單的例子來帶領大家實戰三層架構的項目，這個例子只有一個功能，就是用戶的簡單管理。
首先建立一個空白解決方案，添加如下項目及文件
1、添加 Web Application項目，命名為UI,新建Web Form類型文件User.aspx（含User.aspx.cs）
2、添加ClassLibrary項目，命名為BLL,新建Class類型文件UserBLL.cs
3、添加ClassLibrary項目，命名為DAL,新建Class類型文件UserDAL.cs.添加SQLHelper引用。（這個是微軟的數據訪問類，也可以不用，直接編寫所有的數據訪問代碼。我一般用自己寫的數據訪問類DataAccessHelper ）。
4、添加ClassLibrary項目，命名為Model,新建Class類型文件UserModel.cs
5、添加ClassLibrary項目，命名為IDAL,新建Interface類型文件IUserDAL.cs
6、添加ClassLibrary項目，命名為ClassFactory
相信大家已經看出來了，這個和Petshop的示例沒什麼區別，而且更簡單，因為在下也是通過Petshop學習三層架構的。但一些朋友對於這幾個項目所處的層次，以及它們之間的關系，可能比較模糊，這里逐個說明一下：
1、User.aspx和User.aspx.cs
這兩個文件（以及文件所屬的項目，下面也是如此，不再重復強調了）都屬於表現層部分。User.aspx比較好理解，因為它就是顯示頁面了。User.aspx.cs有些人覺得不應該算，而是要劃到業務邏輯層中去。如果不做分層的話，那麼讓User.aspx.cs來處理業務邏輯，甚至操作資料庫都沒什麼問題，但是做分層的話，這樣就不應該了。在分層結構中，User.aspx.cs僅應該處理與顯示有關的內容，其它部分都不應該涉及。
舉例：我們實現用列表方式顯示用戶的功能，那麼提取信息的工作是由BLL來做的，UI（本例中是User.aspx.cs）調用BLL得到UserInfo後，通過代碼綁定到User.aspx的數據控制項上，就實現了列表的顯示。在此過程中User.aspx.cs對UI沒有起到什麼作用，僅是用來傳遞數據，而且宴帶啟因為實際編碼中大部分情況都是如此的實現，所以使有些人覺得User.aspx.cs不應該算UI,而應該並入BLL負責邏輯處理。繼續往下看，這時提出了一個新需求，要求在每個用戶的前面加一個圖標，生動地表現出用戶的性別，而且不滿18歲的用兒童圖標表示。這個需求的實現，就輪到User.aspx.cs來做了，這種情況下User.aspx.cs才算有了真正的用途。
2、NewBLL.cs
添加如下方法：
public IListUserInfo GetUsers（）：返回所有的用戶信息列表
public UserInfo GetUser（int UserId）：返回指定用戶的詳細信息
public bool AddUser（UserInfo User）：新增用戶信息
public bool ChangeUser（UserInfo User）：更新用戶信息
public void RemoveUser（int UserId）：移除用戶信息
此文件就屬於業務邏輯層了，專門用來處理與業務邏輯有關的操作。可能有很多人覺得這一層唯一的用途，就是把表現層傳過來的數據轉發給數據層。這種情況確實很多，但這只能說明項目比較簡單，或者項目本身與業務的關系結合的不緊密（比如當前比較流行的MIS），所以造成業務層無事可做，只起到了一個轉發的作用。但這不代表業務層可有可無，隨著項目的增大，或者業務關系比較多，業務層就會體現出它的作用來了。
此處最可能造成錯誤的，就是把數據操作代碼劃在了業務邏輯層，而把資料庫作為了數據訪問層。
舉例：有些朋友感覺BLL層意義不大，只是將DAL的數據提上來就轉發給了UI,而未作任何處理。看一下這個例子
BLL層
SelectUser（UserInfo userInfo）根據傳入的username或email得到用戶詳細信息。
IsExist（UserInfo userInfo）判斷指定的username或email是否存在。
然後DAL也相應提供方法共BLL調用
SelectUser（UserInfo userInfo）
IsExist（UserInfo userInfo）
這樣BLL確實只起到了一個傳遞的作用。
但如果這樣做：
BLL.IsExist（Userinfo userinfo）
{
UerInfo user = DAL.SelectUser（User）；
return （userInfo.Id != null）；
}
那麼DAL就無需實現IsExist（）方法了，BLL中也就有了邏輯處理的代碼。
3、UserModel.cs
實體類，這個東西，大家可能覺得不好分層。包括我以前在內，是這樣理解的：UI?àModel?àBLL?àModel?àDAL,如此則認為Model在各層之間起到了一個數據傳輸的橋梁作用。不過在這里，我們不是把事情想簡單，而是想復雜了。
Model是什麼？它什麼也不是！它在三層架構中是可有可無的。它其實就是面向對象編程中最基本的東西：類。一個桌子是一個類，一條新聞也是一個類，int、string、doublie等也是類，它僅僅是一個類而已。
這樣，Model在三層架構中的位置，和int,string等變數的地位就一樣了，沒有其它的目的，僅用於數據的存儲而已，只不過它存儲的是復雜的數據。所以如果你的項目中對象都非常簡單，那麼不用Model而直接傳遞多個參數也能做成三層架構。
那為什麼還要有Model呢，它的好處是什麼呢。下面是思考一個問題時想到的，插在這里：
Model在各層參數傳遞時到底能起到做大的作用？
在各層間傳遞參數時，可以這樣：
AddUser（userId,userName,userPassword,，）
也可以這樣：
AddUser（userInfo）
這兩種方法那個好呢。一目瞭然，肯定是第二種要好很多。
什麼時候用普通變數類型（int,string,guid,double）在各層之間傳遞參數，什麼使用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這三個參數的四種組合模式。UserId其實也可以合並到user中，但項目中其它BLL都實現了帶有id參數的介面，所以這里也保留這一項。
傳入了userInfo,那如何處理呢，這個就需要按照先後的順序了，有具體代碼決定。
這里按這個順序處理
首先看是否同時具有username和password,然後看是否同時具有email和password,然後看是否有username,然後看是否有email.依次處理。
這樣，如果以後增加一個新內容，會員卡（number），則無需更改介面，只要在DAL的代碼中增加對number的支持就行，然後前台增加會員卡一項內容的表現與處理即可。
4、UserDAL.cs
public IListUserInfo SelectUsers（）：返回所有的用戶信息列表
public UserInfo SelectUser（int UserId）：返回指定用戶的相信信息
public bool InsertUser（UserInfo User）：新增用戶信息
public bool UpdateUser（UserInfo User）：更新用戶信息
public void DeleteUser（int UserId）：移除用戶信息
很多人最鬧不清的就是數據訪問層，到底那部分才算數據訪問層呢？有些認為資料庫就是數據訪問層，這是對定義沒有搞清楚，DAL是數據訪問層而不是數據存儲層，因此資料庫不可能是這一層的。也有的把SQLHelper（或其同類作用的組件）作為數據訪問層，它又是一個可有可無的東西，SQLHelper的作用是減少重復性編碼，提高編碼效率，因此如果我習慣在乎效率或使用一個非資料庫的數據源時，可以丟棄SQLHelper,一個可以隨意棄置的部分，又怎麼能成為三層架構中的一層呢。
可以這樣定義：與數據源操作有關的代碼，就應該放在數據訪問層中，屬於數據訪問層
5、IUserDAL
數據訪問層介面，這又是一個可有可無的東西，因為Petshop中帶了它和ClassFactory類工廠，所以有些項目不論需不需要支持多數據源，都把這兩個東西做了進來，有的甚至不建ClassFactory而只建了IDAL,然後"IUserDAL iUserDal = new UserDAL（）；",不知意義何在。這就完全是畫虎不成反類犬了。
許多人在這里有一個誤解，那就是以為存在這樣的關系：BLL?àIDAL?àDAL,認為IDAL起到了BLL和DAL之間的橋梁作用，BLL是通過IDAL來調用DAL的。但實際是即使你如此編碼："IUserDAL iUserDal = ClassFacotry.CreateUserDAL（）；",那麼在執行"iUserDal.SelectUsers（）"時，其實還是執行的UserDAL實例，而不是IUserDAL實例，所以IDAL在三層中的位置是與DAL平級的關系。
通過上面的介紹，基本上將三層架構的層次結構說明了。其實，本人有一個判斷三層架構是否標準的方法，那就是將三層中的任意一層完全替換，都不會對其它兩層造成影響，這樣的構造基本就符合三層標准了（雖然實現起來比較難^_^）。例如如果將項目從B/S改為C/S（或相反），那麼除了UI以外，BLL與DAL都不用改動；或者將SQLServer改為Oracle,只需替換SQLServerDAL到OracleDAL,無需其它操作等等。本來想在文中加入一些具體的代碼的，但感覺不是很必要，如果大家覺得需要的話，我再補充吧。
總結：不要因為某個層對你來說沒用，或者實現起來特別簡單，就認為它沒有必要，或者摒棄它，或者挪作它用。只要進行了分層，不管是幾層，每一層都要有明確的目的和功能實現，而不要被實際過程所左右，造成同一類文件位於不同層的情況發生。也不要出現同一層實現了不同的功能的情況發生。
㈩ 一個成熟的javaWeb項目包含哪些層
一般是三層架構
表現層 web
業務層 service
持久層