三層架構
表示層
業務層
邏輯層
我覺得主要是DAL的效率，這個層應該用COM實現，但是這樣的話，如果是DNA的防火牆又成了問題。
還有，分層後的資源釋放問題。
BLL層的只放邏輯規則就可以了，用它來連接UI和DAL
業務邏輯層(BLL)：主要是針對具體的問題的操作，也可以理解成對數據層的操作，對數據業務邏輯處理。如果說數據層是積木，那邏輯層就是對這些積木的搭建。
數據訪問層(DAL)：主要是對原始數據(數據庫或者文本文件等存放數據的形式)的操作層，而不是指原始數據，也就是說，是對數據的操作，而不是數據庫，具體爲業務邏輯層或表示層提供數據服務。
(IDAL)它體現了“抽象”的精神，或者說是“面向接口編程”的最佳體現。抽象的接口模塊IDAL
(Model)實體和數據庫表映射類
（Web）web網站項目
就按你的要求寫把
需求：
1。需要有一個對象負責接收key
2.改類需要查詢數據
3.該類需要返回數據
約束：該類在實際使用中需要查詢商品表
C# codepublic class seach
{
private string _key
public string key
{
set(_key=value;)
}
private object _Result;
public object result //返回值，這裏使用object是爲了留出空白，保留該類的變化
{
get
{
return _Result;
}
}
public virtual void getSearch() //查詢數據，這裏使用virtual同樣是爲了留出空白，保留該類的變化
{
}
}
你可以看到這是一個純粹的對象，沒有做任何數據庫要做的事情，也沒做界面要做的事情，他完全是對需求的一個代碼翻譯
這個是實際上是MOdel的東西
2.有了model層，我們在做業務邏輯,業務邏輯我們要完成對這個對象的約束
C# codepublic goodsSearch:seach
{
public Dataview seachRes //返回結果
{
get(return (DataView)_Result;) //這裏我返回了DataView,實際上你可以返回別的東西，只要你能轉換的過去
}
public goodssearch(string key)
{
_key=key;
}
public override void getSearch()
{
_Result=DAl.xxx(_key)//去數據層取數據，當然數據層怎麼寫是數據層的事情，這裏就不要關心了
}
}
3.數據層，這個我就不寫，基本就是把你自己寫的訪問數據庫的東西在寫一遍，你明白就可以了
現在你可以看的比較清楚了把，實際上三層的模型完全就是在將就對象設計，而在對象設計初期，我根本就沒管數據庫和界面的事情
實際上的區別在於考慮問題的方式，就PetShop而言，從界面層考慮，他的業務邏輯層沒問題，完全合用，數據層也沒問題
問題在於：PetShop根本就不是開始從界面層考慮問題，他一開始就是從model層開始的，所以最終表現成了現在的架構。
所以，你該把你的眼睛放到model層，由model層看其他層的東西
這個東西，我可以毫不客氣的說（我不怕得罪人）建議看petshop的，而沒點出爲什麼要看PetShop的人，實際並不明白爲啥要分層。對於這些人，我說是馬後炮，中國隊贏了，你們說中國隊戰無不勝，中國隊輸了，你們說中國隊就是一羣“豬”
將DataLayer放在App_Code文件夾下他還是業務邏輯層，不管你把它放到哪，都是業務邏輯層，軟件分層在於思想和歸類，而不在於文件擺放的位置。
數據層：一般只包括數據庫那塊，而且也不包含大量的存儲過程，按照數據層的概念，就是提供簡單的數據存儲維護任務的。
邏輯層：一般就是指我們寫的程序的邏輯處理部分不包括界面。這個其實很難區分，例如數據訪問層根數據層容易混淆，其實我明確不了它算什麼，還有網上流行的數據持久層也就是被稱爲ORM的大型框架，按照理論來講它大部分功能應該是屬於數據層的應該劃爲數據層，但是實際架構中又與數據庫沒密切聯繫，所以有人把它分離出來叫數據持久層，我覺得在軟件開發中沒必要非得用這麼大規模的框架做性能緩衝，那還不如用多個數據庫軟件做，小型的數據緩存，可以通過其它緩存方式來解決。但事實表明中國人都是很懶的而且很想節省開支，所以很氾濫的在用這些東西，從而也導致了中國軟件性能的各種問題，“慢”是一個最明顯的問題。數據方面的邏輯處理的方法就屬於這層，如果這樣說的話，複雜的邏輯存儲過程其實也是屬於這層的，用一兩個倒沒什麼，最讓我難以理解的是，大部分人大部分公司都在以各種程度的濫用數據庫的存儲過程，一個很小的處理都用存儲過程寫，這到底能給你帶來多大的方便呢？如果改動你也不可能只該存儲過程還是要改程序，而且這樣做無形的就給數據庫增加了一層壓力，這也是爲什麼大多數軟件程序還爲垮，數據庫先垮掉的一個原因之一。
表示層：其實就是用戶界面了，這些基本的控件操作阿，什麼的都是。
以上僅爲個人經驗所得，僅供參考，我也希望中國軟件界多一些能自我開發的人才，而不是隻能用一些成熟的框架做二次開發的人才。拿來的東西是未必都很好用，要充分了解它的特性，有選擇的使用。
ASP.NET多層結構
作者/發佈者:流水
實際 PetShop4是三層擴展出來的，用七層模擬做了兩個小項目，實際和三層沒區別，只是多了反射和接口。但是項目強壯了很多，可以順利過渡任意數據庫可以靈活切換數據庫不改源碼，很好的實現了OCP原則，至於上層換BS或換CS 分三層就能夠靈活實現，所以對七層的理解很重要.
所以我上面說能把三層講清楚就不容易了...
factory和ioc是什麼？請去查清楚概念再想想它們和分層的關係...
分層是一種工程方法並非開發技術...
舉個不太恰當的例子：
我現在穿T恤+牛仔褲+休閒鞋，當然我還穿內褲和襪子，然而所有人都知道我這身裝扮的架構是上衣+褲子+鞋...沒有人會拿自己的內褲出來炫耀...
天氣再冷一些我會再加外套，更冷的時候我會再加保暖內衣...需求變化了，然而它的架構依然是上衣+褲子+鞋...
如果我去寒冷的北方會再加毛衣和大衣鞋子也會換成靴子襪子可能穿兩雙，如果我去登珠峯我會加更多更專業的禦寒裝備，需求變化導致我擴展我的架構...然而它的架構依然是上衣+褲子+鞋...不管我穿了多少條褲子它們只有一個功能——保護我的下肢——我認爲它們是一個層次的東西...
其實我感覺在分層的意義上,可能各個人對層的深淺不同，所以出來的層也不同吧.
如果:
褲子 = 保護下肢
褲子+鞋 = 保護下肢
上衣+褲子+鞋+ 兩雙襪子 = 保護下肢
如果說以上三個選擇是一個層次的東西,那退一步來看,穿着的基本功能都是爲了保暖的,上衣+褲子+鞋是不是可以看成是一層(因爲功能一致)呢?
分層的概念:分層表示將功能進行有序的分組.
我覺得當鞋或襪子加入時,它們的功能與褲子是不同的,於是,將他們的功能進行分組是可以出新的"層的",這樣分層有多了一層.
我覺得架構和分層還是有區別的.
工程方法是從實踐中來到實踐中去，是爲了解決實際問題的...
化繁爲簡見功夫...化簡就繁是庸才...
邏輯層和物理層不是一回事，一個項目只是一個物理上的概念，不是邏輯上的。
分層的目的
爲了多人開發方便
1 開發 個人開發，我想怎麼開發怎麼開發，那是我的問題,分不分層無所謂的事情
多人協作開發
一人開發一個模塊，各不相干的開發,那麼模塊之間的調用肯定是接口最恰當了
2 佈署
佈署你把bll.dll和model.dll放到二個服務器上.這，顯然不恰當 ,那麼分佈式佈署也僅僅是說web服務器和數據服務器不在同一服務器上
3 維護
如果bll出了問題那麼我們更新一個bll然後再上傳這個dll，顯示是很方便的
事實上,就面對對像來說如果某一類某一方法出了問題,一般的解決方法是重寫子類或是再繼承一個類重寫掉 這樣不會影響其它類， 這就要求我們在開發時候一定要規化好類層次
事實上,分層主要是分類的層次,主要是爲了方便維護和管理
一個程序員寫出來的程序不能擴展，不能改良，這個程序員只能是代碼工人啊， 苦口婆心，絕對沒有傷人的意思。 可以看看一些分層的開源項目，對自己絕對沒有損失。
並不是每個系統都要分層，一般只針對一些大型系統才採用分層，你看PetShop4，總共有22個項目。
大體思想是3層，從Model,DAL,BLL，
然後他在各層上又採用了工廠模式，把邏輯與實現想分離，比如以前BLL直接調用DAL就好了，
但現在BLL卻調用了IDAL,IDAL只是一個接口層，裏面封狀了要完成的一些業務邏輯，
而具體的實現則交給DAL去實現，
然後藉助於工廠模式DALFactory和映射完成IDAL層中類的實例化。
這樣不管我們用的底層用的是什麼數據庫都可以完成BLL對DAL的調用。
另外，從分層角度來看，你的分層至少也不標準。
首先你不應該將那些SQL語句放在BLL層中，而應該是由DAL層來完成和數據庫的交互。
要想研究分層模式，PetShop4的確是一個相當好的例子，值得學習。
在.NET中 DAL+IDAL+Model+BLL+Web是什麼意思
業務邏輯層(BLL)：主要是針對具體的問題的操作，也可以理解成對數據層的操作，對數據業務邏輯處理。如果說數據層是積木，那邏輯層就是對這些積木的搭建。
數據訪問層(DAL)：主要是對原始數據(數據庫或者文本文件等存放數據的形式)的操作層，而不是指原始數據，也就是說，是對數據的操作，而不是數據庫，具體爲業務邏輯層或表示層提供數據服務。
(IDAL)它體現了“抽象”的精神，或者說是“面向接口編程”的最佳體現。抽象的接口模塊IDAL
(Model)實體和數據庫表映射類
（Web）web網站項目
1.兵無常勢，水無常形
2.吾常聞拙速，未嘗聞巧以久也
3.運用之妙，存乎一心
形式真有那麼重要嗎？？世人皆稱 二萬五千里長徵是奇蹟，但這個奇蹟是一個無奈的奇蹟，是需求和條件決定的，你會無緣無故的去做二萬五千里長徵嗎？？
三層開發
我想到我以前對其的理解 也只是數據,邏輯,表現
但如何區分它們,實在太難
後來,對其深入的思考 數據層 不過是從數據庫取出數據,
邏輯層是邏輯的實現功能,表現 就是 呈現出來.
有一個方法區分用多少 就是上樓模型.
你必須從一樓一樓上,不可跨越任何一層.
如:當你從一樓到二樓,不論你走那個樓梯,都可以到二樓,
這些樓梯可以看作一層.
分層是工程方法...
設計模式也是工程方法...
工程方法的最終目的不是技術層面的東西而是TCO...從純技術的角度去理解分層永遠都是紙上談兵...
我寫過七層的模塊,有過兩次,
我們大部分開始構架的時候是五層,然後再整理分析七層就出來了,
沒有什麼亂的啊,感覺很好,方便調用.不像樓上有些人說的那樣[把問題複雜化了].
項目較大的,我想七層是最好的選擇了.
三層
UI層
邏輯層
數據層
已經很經典了,當然不是我說了,但是裏面還是可以繼續分的,主要是爲了開發便利.
7層沒什麼,很正常. 只是樓主沒真理解7層,實際上所謂7層還是3層!! 無非是分的更詳細些,比如提供了接口層,實體層(參數數組)等等
七層是正確的，這帖子討論的時候我還沒開始分析PetShop。
實際 PetShop是三層擴展出來的，用七層模擬做了兩個小項目，實際和三層沒區別，只是多了反射和接口。但是項目強壯了很多，可以順利過渡任意數據庫可以靈活切換數據庫不改源碼，很好的實現了OCP原則，至於上層換BS或換CS 分三層就能夠靈活實現，所以對七層的理解很重要，如果鄙視技術思想還做技術做什麼，不用就不用，用不着站着說話不腰痛。
factory 獨立出來 主要是爲了直觀，分七層 如果接口和方法都定義好後，任何一個有基礎的程序員都可以參與大型項目。 項目風險降低很多，節約很多時間。
層，無所謂有，無所謂無
層在心中，層的最高境界是 無層
---DBUtility數據層基類
---DALFactory數據層工廠類
---IDAL接口層
---SQLDAL接口實現層
---Model實體類
---Logic業務邏輯層
---Web表示層
友情合作伙伴：第一網絡（http://w1.org.cn）！本文出自：http://w1.org.cn/web/programming/layer3.html
跟隨商鞅的腳步...
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/gumanren/archive/2010/01/12/5180690.aspx