3層架構vs 2層架構

我們真正需要3層架構的例子是什麼？大多數使用3層架構的應用程序是否可以使用2層架構來完成？3層架構vs 2層架構

注：我想看到3層架構的價值，我覺得大部分的應用程序，有3層，現在可以在2層來完成，所以我找實例，我們絕對需要3這種需求並沒有例外。

2009-10-25 Rachel

*「我找實例，其中我們絕對需要3層，沒有例外「* - 這個行業真的沒有什麼是明確的。事實上，有幾百種方法來處理每一個問題，任何方法都有其自身的優點。人們已經做了這麼長時間，以至於某些方法出現，這些方法在經驗上解決了比他們創造的更多問題 - 而這些方法成爲行業準則/模式/最佳實踐。相信在任何情況下，一種方法是絕對正確的，而另一種方法是絕對錯誤的，這是一種謬論。 – MattDavey 2013-04-22 08:25:28

我猜你的意思是分層（分離的邏輯單元）而不是分層（物理單元的分離/部署）。分層系統的一個例子是一個網頁服務器（1層）提供網頁（另一層），它從第三層的數據庫中提取數據。

分層架構的通常目標是分離責任。這有兩個關鍵的好處（其中包括）。

首先，您的設計將更清晰，責任不會混淆，因此代碼將更易於閱讀，理解和維護。

其次，您可能會減少重複 - 例如，如果您的頁面也在處理業務邏輯（或恐怖數據訪問的恐怖）以及顯示頁面，則可以在Web應用程序中實現，多個頁面將嘗試做相同或類似的事情。

你並不需要到建築師（例如成層，雖然也有其他方式）的任何一款軟件，但是從瑣碎的事情除了東西如果不這樣做的結果將是一個不可維護的混亂。

來源

2009-10-25 15:51:19 FinnNk

-1

那麼，如果你有一個網站...你可能有一些Javascript代碼，所以這是一個層，你有你的業務邏輯在服務器，你有數據庫來存儲的東西。我認爲這是三層。當然，你可以在數據庫中使用存儲過程並跳過業務邏輯層，這樣可以建立一個兩層的網站，但如果你不想使用存儲過程，你將有三層。

來源

2009-10-25 15:53:51 tuinstoel

業務邏輯不應該駐留在存儲過程或數據訪問層中。我更喜歡將數據庫視爲對象 - 存儲過程的方法以及作爲數據實體的字段。存儲過程以最有利的方式處理從數據庫中獲取數據以及實現SQL自身的任務 - 例如，基於多條記錄上的連接更新列。 – 2009-10-25 16:16:19

@ztech，是啊，那麼......？每個人都有偏好和觀點以及'不應該'。與OP的問題有什麼關係？ – tuinstoel 2009-10-25 17:26:28

關鍵是鼓勵良好的設計實踐。例如，如果有人問如何將超過512個文件放入Windows 95的根目錄中，我的第一個迴應是「不要，因爲這是一個壞主意。」試圖鞏固你的應用中的圖層幾乎總是一個壞主意，而我，其中一個，不想結束後來出現的那個人，並且必須保持那種廢話。不鼓勵業內糟糕的設計讓我們的生活變得更輕鬆。 – 2009-10-25 22:18:23

道具FinnNk，但讓我給你一個例子，當你不分層時會發生什麼。多年來，我一直在做一個在出生時嚴重分離的項目。所有三層 - 如果您相信tuinstoel所說的話 - 更多的是集中到各個JSP頁面。我相信它當時看起來是一個聰明的東西（當你剛開始的時候編碼會更快），但是這個怪物已經增長和增長，沒有人花時間重構。

我們現在有2000多個JSP頁面，其中遍佈着重複的代碼。改變模式需要仔細回溯，找出可能影響的頁面，並對每個頁面進行單獨測試。管理層中沒有人認爲重要的是花時間來解決這個問題 - 短期收益，長期虧損。

做。不。走。這個。路線。

分離層導致更好，更快，更可測試，更模塊化的代碼。你會爲此感謝你，並且（更重要的）你會感謝你的人。

來源

2009-10-25 16:06:46 Maas

某些數據庫向外界展示了一個休息界面，例如NoSQL數據庫CouchDB和RavenDB。這意味着瀏覽器中運行的Javascript可以在沒有中間層的情況下調用數據庫。

參見例如：http://www.infoq.com/news/2010/06/couchdb

「表現良好HTTP/REST接口和 API清潔和簡單的兩層應用程序（HTML + JavaScript中的瀏覽器+榻+ JavaScript作爲服務器）」

Oracle內部有一個Web服務器，您可以使用存儲的特效，同時向外界展示休息界面。因此，瀏覽器中的JavaScript也可以在沒有中間層的情況下調用Oracle數據庫。

你是否總是需要一箇中間層，當你想要從數據庫中獲取一些數據？我質疑這種需要。

（TTT原名Tuinstoel）

來源

2010-08-31 03:46:11 TTT

只是好奇，你在這種情況下如何處理安全？我很好奇。 – 2010-09-01 00:40:01

可能會推動你擺脫2層至3層的一些情況： 1 - 您的系統擁有不同類型的客戶端（臺式機，網絡，手機等） 2-您的系統具有不同類型的數據源（例如，非數據庫資源）
3-您的系統需要特定的客戶端/服務器通信協議 4-您希望隱藏和保護客戶端的數據層 5-您需要服務器集羣和負載均衡的可擴展性 6-您需要服務器到服務器的集成，對客戶端來說是透明的 7-您希望將共享資源用於多個客戶端（例如數據庫連接） 8-您希望通過將客戶端從數據庫服務器或服務器組中解耦來簡化系統維護9-您希望將業務邏輯放入單獨的層在特定平臺上 10-您希望減少客戶端和數據庫之間的流量

來源

2013-04-21 17:54:17

首先，很好的問題。正如其他人所指出的，兩者都有優點。「關注的分離 - 」是3層的主要優點和幾種方法，支付股息：

安全性：通過從演示分開你的業務邏輯，則可以採取更爲嚴格的政策，各個層例如沒有數據或邏輯的演示文稿表單可以位於演示文稿區域，這樣匿名用戶就可以訪問您的「公開」內容。
可維護性/可管理性 - 已經對此說過很多
重複使用/災難恢復：例如，如果一個治療管理應用可能想要公開一個UI以及第三方可用來發出處方訂單的服務。按業務邏輯分離成一個單獨的層，可以獨立於UI

有幾個人的維護服務/邏輯，但這些希望得到的潛在好處的想法

來源

2015-01-20 16:41:50

3層架構vs 2層架構

回答

相關問題