3層體系結構分層和術語混雜

我對錶達3層體系結構的不同可能性感到困惑。3層體系結構分層和術語混雜

Data-Access-Layer 
Business-Layer 
Presentation Layer (User Interface)

或

Database (aka Backend) 
Business-Layer 
Presentation Layer (User Interface)

爲什麼你可以跳過在第一方法的數據庫？兩者都使用數據庫！數據庫是否屬於分層？

什麼是錯，什麼是正確的？

有人能澄清這一點嗎？

來源

2010-04-14 Rookian

Data-Access-Layer 
Business-Layer 
Presentation Layer (User Interface)

數據訪問層不一定是一個數據庫。它可能是一個XML文件。它可能是一個RSS提要。它可能是一個外部應用程序。它可能是任何你喜歡的東西，將數據導入你的應用程序。

所以這是真的：

[Data-Source] 
Data-Access-Layer 
Business-Layer 
Presentation Layer (User Interface)

其中[Data-Source]是數據庫，XML，RSS，什麼...我更願意認爲該數據源本身作爲一個司機，而不是一個層。

此方法的靈活性允許您在不觸及應用程序的其餘部分的情況下更換數據源。因此，如果您開始使用XML文件作爲後端數據，然後您想要將其更改爲數據庫，則只需觸摸DAL層 - 只要它仍然獲得，DAL層的其餘部分就不會在意數據格式相同。

來源

2010-04-14 11:57:47

術語數據源是interssting。對我而言，這個術語表示數據庫沒有邏輯。這個假設是正確的嗎？什麼時候我的數據庫包含整個業務邏輯？我是否還有業務層？ – Rookian 2010-04-14 12:01:18

您會發現很多關於將業務邏輯放入數據庫是否「正確」的討論。如果您決定將數據庫服務器從MS SQL更改爲MySQL，會怎樣？突然你必須重寫你的業務邏輯。如果您完全刪除數據庫並使用XML，那該怎麼辦？你的邏輯消失了。此外，如果您的業務邏輯在數據庫中毫無意義，那麼您將在兩個地方維護業務邏輯 - 一個糟糕的主意。其他時候，業務邏輯只能在數據庫的上下文中運行。你必須根據你的具體情況來定製抽象 – 2010-04-14 12:05:56

http://en.wikipedia.org/wiki/Business_logic從兩個角度提供文章。 – 2010-04-14 12:09:58

你認爲你的dal可能不會使用一個數據庫它可以使用一個XML文件？

第一種方法是使用更抽象的概念，即3層圖層。

每層中的東西取決於層的實現。 Yuo可能會發現你在GUI/DB/BizLogic的'程序'之間混合了你的圖層，但是在抽象中你仍然保留了這些圖層。

數據訪問層
業務層
表示層（用戶界面）

考慮到上述可能WIRTE連接到你的數據庫的代碼。那是DAL還是邏輯？

我會認爲你正在寫代碼來訪問數據的DAL。

來源

2010-04-14 11:53:53

表示層
這是應用程序的最高級別。表示層顯示與諸如瀏覽商品，購買和購物車內容等服務有關的信息。它通過將結果輸出到網絡中的瀏覽器/客戶端層和所有其他層來與其他層進行通信。
應用層（業務邏輯/邏輯層/數據訪問層/中間層）
邏輯層從表示層抽出，並作爲其自己的層，通過執行詳細處理來控制應用程序的功能。
數據層
該層由數據庫服務器組成。這裏存儲和檢索信息。該層保持數據中立，並且獨立於應用程序服務器或業務邏輯。爲數據提供自己的層也提高了可伸縮性和性能。

參見下面的更多細節：
http://en.wikipedia.org/wiki/Multitier_architecture

來源

2010-04-14 11:55:06 Brij

微軟的模式和實踐小組有一個很好的architecture guide，經歷了這個問題的所有變化。它稍微專注於.NET，但非常適用於任何環境。強烈推薦。

來源

2010-04-14 12:04:07

3層體系結構分層和術語混雜

回答

相關問題