那東西主要就是將應用邏輯（業務、商業邏輯）抽象出來，與前端表現介面分開，從而體現三層、多層結構的易拓展、易維護性的特性。
業務邏輯又分為業務規則和業務外觀
分開設計的目的是提高應用程式的可伸縮性和可維護性。如果你的應用程式在執行一段時間後，需要修改某些業務規則，你不需要對其它部分做大量的改動，如果你的程式結構做的很好的話，甚至可以不需要對其它部分進行變動。
.net技術的架構應用
對資料合法性的校驗放在前台，而對資料的計算等處理放在後台
不可能把所有邏輯全部放在後台，這樣看起來邏輯清晰了，但是效率太低了。
所謂的業務邏輯和介面的分離，並不是在cs不需要，在bs或多層就需要。
其實這是社會分工越來越細的要求，也是物件導向的開發的要求。
拿企業級應用系統來說，每個企業的需求都是不同的，對於介面的需求也不同。
在別人的指導下能調整調整介面的程式設計師，隨時能找到。而能編好業務邏輯的程式設計師真的非常難找。因此你要讓高水平的程式設計師去把注意力集中在業務邏輯上，不不用花時間去調整介面。
我們做的是cs結構的，我們的做法是在所有的form裡都不直接使用dataset,而是在相關的datamodule中放dataset, 並且建立專門的業務處理類，其中包括dataset, form中只是呼叫datamodule和業務類中的函式。而不會把介面操作和業務處理混雜在一起。我們基本消滅了100行以上的函式。每個函式都短小清晰明確。
1，客戶端：基本的資料瀏覽，資料驗證；（強調乙個瘦字），所以資料傳輸最少化，這種最少化應該通過中間層的控制來達到。
2，中間層：企業邏輯層，複雜的演算法和邏輯規則；(強調乙個全字），所有客戶端的要求都由中間層來控制，包括到資料庫取資料（取多少，取哪些），因為要滿足很多客戶端，所以這些要求不是和客戶端一樣的。
3，資料層：保證提供中間層所有的資料和保證對資料的各種操作能夠順利進行。
分層的目的是為了實現分布式，控制整個系統的平衡負載，故障負載，實現系統的柔性。
一般來說，中間層建立完整的企業com+邏輯元件物件，完成客戶端需要的全部服務，中間層對資料的操作一般來說不使用針對某些資料庫的儲存過程和其他一些東西，因為要實現對不同資料庫系統的控制。使用中間層元件能夠更好的實現**的重用，如果我們應用物件導向的方法考慮時，客戶端：發出指令和要求，同時得到反饋，中間層：正確完成指令要求，並反饋，資料層：提供指令所需要的資料，儲存返回來的資料。
在考慮兩層的時候，我們考慮的服務端不多，很多人心中只是乙個，其實服務端也很多，有時候客戶端和服務端交雜，如果你提供服務，你就屬於中間層，如果僅僅是發出指令，就是客戶端。
對大量的資料的表，是不能一次取出，就算按照clientdaset分批取的話，在應用伺服器上，也會快取乙個大的資料集，同樣影響效率。
所以應該由客戶段傳送sql語句。取少量資料，同時伺服器不維持這個狀態。如客戶段需維護。根據控制項及摸班很容易動態拼出sql語句到應用伺服器執行
我覺得我們在討論b/s和c/s，或者兩層和三層時，應該理解他們的特點和主要解決的問題。
我覺得把介面和業務邏輯分離最大的好處是可重用，這一點不一定是在乙個專案中體現，而且在一系列開發的專案中都可以重用或只修改業務邏輯。業務邏輯的設計我覺得要結合oop的思想，把一堆c/s程式中的業務邏輯處理函式什麼的搬到應用伺服器中，我覺得沒有體現三層的真正含義。
三層架構的提出，我覺得主要是為了大型的，使用者數目很大的，業務特別負責甚至經常修改的專案，所以有負載均衡、客戶易維護等特點。但我們國內更多的專案並不具備這些特點，所以會覺得標準的三層構架很理論，我覺得我們應該根據系統的特點來選擇的兩層或三層的技術。
象連線池這些技術，實際上是犧牲速度保證使用者數，如果我們專案本身使用者數不多，我覺得就可以保持資料庫連線開啟，以保障速度。
再象返回資料集也一樣。一味減少返回資料集的記錄數肯定會加大使用者的操作時間，不管是讓其輸入檢索條件還是通過翻頁。（當然有些技術並沒有這麼大的***）
總之，我覺得三層架構有其先進性，關鍵看我們如何結合具體專案來取捨其中的技術。就象圍棋，所有定式基本上都是利益均衡的，但結合具體的一盤棋就有不同的選擇。我們就象那些下棋的人，還 沒有水平發明定式，只能研究一下各有什麼特點，該怎麼用？
發表自己的拙見，如果不對，請別...哎呀，誰踢我:)
業務模型 業務概念建模 系統模型 應用邏輯架構
從方法到思維 什麼是應用邏輯架構的正確姿勢？職責明確，某種粒度的模組 包括域 元件 系統 包 類 方法 上述模組之間的明確的關聯關係 若干約束和指導原則 軟體設計本身，模組，粒度，職責，復用，等等，在講解軟體設計的時候，使用的是這個架構圖，這個架構圖是通過系統模型和業務概念架構推導而來。所以系統模型...
電商業務簡單下單邏輯
買了東西，提交訂單，訂單確認的過程，減庫存，減優惠券，減餘額，在操作失敗時，需要回退等 使用者 訂單系統 商品服務 優惠券服務 使用者服務 確認訂單邏輯 1.校驗合法性 2.儲存訂單，使用者不可見 3.減庫存，件優惠券，減於額 4.確認訂單 確認成功 確認失敗 傳送失敗訊息到mq 庫存服務監聽，回退...
JDBC的業務邏輯的應用
檔案的定義規範 dao.j a檔案內容 package com.sk.jdbc.dao import j a.lang.reflect.parameterizedtype import j a.lang.reflect.type import j a.sql.connection import j ...