這是一個分層的體系結構嗎？

我在將軟件設計與建築模式進行映射時遇到困惑。這是一個分層的體系結構嗎？

下圖描述了我的主張。 enter image description here

我想問問是什麼 -

是第三層真正的一層或二層的只是一個組成部分？
第四層是構建我的所有軟件的資源。他們是那些不提供服務的人，但是所有的工作都完成了，所有的工作都完成了。他們是否被包含在架構描述中？

來源

2013-03-30 khoks

圖像太小，根本無法辨認出任何東西。 – Koterpillar

好吧，我點擊了鏈接http://s20.postimg.org/gjuxkg0al/for_stack_overflow.png現在它的分辨率非常大。你確定你的瀏覽器沒有顯示縮小的圖像嗎？ – khoks

現在看起來不錯，或許被重新上傳了。 – Koterpillar

圖層不是一個確切的術語，它可以根據您的需求進行定製。這就是說，我會安排你的設計有一點不同：

你的第三層其實是一個面層/包，提供的服務，您的主要軟件流程，但不會對他們有積極的作用。更合適的做法是將其與可以根據需要與所需服務進行交互的2個第一層一起使用。
第四層確實不應該成爲你設計的一部分，因爲它實際上是你係統之外的實體的描述。您可以概述這些實體的接口，但它們不會在您的系統中構建層。

您還可以看看設計描繪了一個更加正式的方法 - 檢查UML的Package diagrams和Layer diagrams（不標準，但接近你尋找什麼）。

來源

2013-03-30 06:44:07 SomeWittyUsername

這裏的問題在於，第三層（工具和服務）僅由第二層（Command API）使用，而不是由GUI使用。我介紹了第二層來隱藏GUI中的服務和工具的細節。我的設計遵循嚴格的從上到下的通信流程，如在TCP/IP協議套件中。另外，我不能將第三層視爲一個側面組件，因爲我的所有功能最終都是由這個服務/工具層執行的，而且它對於每個操作都是必需的。你說得對，我認爲這應該是第四層，這應該通過對它的懷疑來清除 – khoks

如果工具和服務僅用於第二層，那麼最好將它作爲第二層的一部分。保持正確的範圍很重要 – SomeWittyUsername

我也這麼認爲。但是，然後，根據分層架構模式，每一層都只針對其上層。即使第二層僅由GUI層使用。我雖然最初將第二層和第三層分組爲一層，但由於工具和服務沒有任何統一的主題/界面。但是，即使在TCP/IP協議套件中，每層都有多種協議可供選擇，這些協議是相互獨立的。而且，對於API，應用程序編程接口層封裝了常用功能的較低層。 – khoks

這是一個分層的體系結構嗎？

回答

相關問題