如何設計Web應用程序的圖層體系結構？

我有設計問題時，實現1簡單的Web應用程序。我使用struts2 web控制器，spring的IOC和Hibernate作爲持久層。如何設計Web應用程序的圖層體系結構？

因爲這個Web應用程序在乞討時非常簡單。所以我只有2層： 1用於訪問數據庫的DAO層。幾乎每個表都有相關的DAO。 2操作層。用戶struts2。我很滿意這個架構，因爲可以快速實現我的web應用程序。隨着項目變大，我發現動作層變得龐大而複雜，而且很難重複使用。我嘗試創建服務層，解決複雜的業務邏輯是好的，但我的應用程序仍然有很多簡單的邏輯。例如：加載1個對象，保存1個對象，並通過某些條件獲取集合並將其顯示到網頁。如果給每個簡單的DB訪問方法都有相應的服務方法。仍然花費很多努力。如何解決這個問題？我認爲，如果服務層存在，直接調用DAO層還是不適合我的應用程序設計。這種小型Web應用程序有什麼好的解決方案嗎？

來源

2013-12-11 Bensson

當計劃Web應用程序中的不同層時，最好是在不提供身份上下文的情況下明確保護模型中的屬性和關聯以免被操縱。

這是不應該在DAO層或Controller中完成的。您應該將DAO層包裝在服務層中，並讓控制器僅直接與服務而不是DAO進行通信。

保護您的模型免受不必要的操作意味着您可以將Controller和Service之間的數據結構中傳遞的信息量調整爲您要執行的實際操作。例如：向集合中添加或刪除元素是服務中的顯式操作，它不會通過將集合操作爲DAO對象的成員並將該DAO傳遞迴服務來隱式發生。

而不是你的服務可能是這樣的：

+ getAllCompanies(): CompanyType[*] 
+ getAllEmployeesOfCompany(c: CompanyType) : EmployeeType[*] 
+ addEmployeeToCompany(e: EmployeeType, c: CompanyType) 
+ removeEmployeeFromCompany(e: EmployeeType, c: CompanyType)

這種架構的另一個好處是，服務層充當您的交易邊界。事實上，使用控制器的方法作爲交易的邊界實際上是一個非常糟糕的習慣。你甚至可以稱之爲反模式。爲什麼？因爲例如這意味着當你的客戶端掛起時它會回滾你的交易。這在99％的案例中顯然是不需要的。

來源

2013-12-11 08:01:45 mwhs

嗨mwhs，謝謝你給我這麼詳細的建議。我完全同意大中型網站項目的解決方案。但對於我們的小型Web應用程序。雖然服務器層可以幫助解決一些重複使用的問題，並使我的代碼看起來不錯。但是我仍然花了很多時間包裝這些簡單的DAO方法，甚至在服務器層中給出了有意義的名稱。順便說一句：我使用OpenSessionInViewFilter，因爲我的項目很小。 – Bensson

如果時間是你最糟糕的問題，我建議你嘗試生成一些代碼，而不是鍵入它。通常，模型驅動方法（MDA/MDSD）將爲您節省大量重複性任務。查看Acceleo項目。 – mwhs

或者嘗試使用Apache ISIS這樣的領域驅動框架之一，這會從您身上帶走很多工作。 – mwhs

正如@mwhs所評論的那樣，Apache Isis爲您的應用程序分層提供了大量指導。要弄清楚它是否符合你的要求，你可以通過我在最近一次會議上提出的這個tutorial。

來源

2013-12-17 19:48:21

如何設計Web應用程序的圖層體系結構？

回答

相關問題