體系結構：如何創建多個圖層的原則

正如我們所知，幾乎每個複雜的體系結構都包含多個圖層。在管理系統中，我們可以輕鬆地創建數據訪問層，業務邏輯層和表示層，而不需要太多的思考。我想知道如何創建多個圖層是否有明確的原則。 PS：它不限於管理系統。體系結構：如何創建多個圖層的原則

2011-12-01 Dagang

在軟件工程中，設計系統時，必須遵守某些設計原則。如果你這樣做的話，這些圖層幾乎都是獨立出現的。有些原則是：

還有其他人。你可以在網上閱讀它們或者獲得Robert Martin的一本書，書名爲「Agile Software Development, Principles, Patterns, and Practices」

這是本書的鏈接relavent chapter。

2011-12-01 04:40:01

我認爲，主要分層原則是Separation of Concerns。它不一定是面向對象的設計，而是軟件工程範圍的（維基百科文章提供了堆棧協議作爲例子）。因此，通常我們可以找到功能區域（F1，F2，F3）並強制自己設計只有其中一個組件的組件。我們問「X是什麼」？如果回答「F1，F2，F3」，我們將X分成X1，X2，X3，它們分別執行單個功能，但是做得很好。

只是一個短暫而誇張例如

class SomeBusinessObject //Business logic, as we think 
{ 
    bool HasAccess(User loggedInUser) 
    { 
      /* two lines below are clearly from DataAccess layer */ 
      string q = "select 1 from user_roles where id={0} and isadmin=1"; 
      bool hasAccess = DataAccess.Execure(q).Rows > 0; 
      if(!hasAccess) 
      { 
       /* message pre-formatting is Presentation layer concern */ 
       var msg = string.Format("<b>You don't have access</b>"; 
       throw new SecurityException(msg); 
      } 
      return true; 
    } 
}

在我們上面的BL-類應該瞭解數據模型和數據訪問細節樣品;它也會嘗試預先格式化基於HTML的UI的消息。因此，我們可能會將格式移至視圖;並將SQL查詢生成提取到DAL。

一般來說，可以有以下層：

表示層
- UI呈現層（典型地觀看）
- 表示邏輯（演示者/控制器）
服務層（可以在相對較小的系統中省略）
業務邏輯。如果我們想要分層，我們可以考慮：
- 業務規則圖層。
- 驗證圖層。
- 業務邏輯本身。
- 數據轉換
- 查詢服務
數據訪問。可以分爲兩層：
- 抽象數據訪問服務業務層
- 以下爲「DB」層的具體實現。

一般而言，有兩個層關係規則：

層應「交談」只有下面的層。（例如，從DAL到BL應該沒有依賴關係，比如說BL對於表示）。
圖層不應該「跳過」圖層。（演示文稿不應該與DAL交談）。

但是，也有橫切功能，這些功能並沒有真正綁定到任何層。對於日誌記錄，緩存等來說，這大部分都是如此。有些人也可能會說安全問題，但我確信可以按照特定層次的方式來完成。

希望有所幫助。

來源

2011-12-02 10:16:56 mikalai

分層架構風格意味着調用層次結構。對於某些被認爲是單獨的層的應用，應該限制其與其他層的通信模式。一個圖層爲它上面的圖層提供功能，並使用上面的圖層功能。在純分層系統中，層只能看到層次結構中的1個步驟（例如TCP/IP協議體系結構）。

分層優勢包括增加鬆散耦合和不同層的可演化性。層的主要缺點是你添加延遲和複製數據（通過層到層） - 所以你必須考慮鬆散耦合與添加延遲當決定一個新層

除此之外，你應該請注意層與層之間的差異 - 或者始終位於同一臺計算機（層）上的圖層以及跨越計算機（層）的邊界層。當分佈圖層時，您需要注意的不僅僅是延遲（請參閱fallacies of distributed computing），因此您應該有充分的理由添加層

來源

2011-12-02 14:01:58

體系結構：如何創建多個圖層的原則

回答

相關問題