2012-07-28 50 views
1

我試圖改進我的代碼結構,所以或許我可以得到關於如何處理主要服務的以下幾點和問題的一些輸入。MVC代碼構建最佳實踐問題

  1. 服務不應該依賴表現層,所以通過這樣的東西的HttpContext到服務/服務功能,通過構造和相似的是一種不好的做法,是否正確?

  2. 應該沒有互相引用的服務嗎?他們是否只能像「存儲庫依賴」那樣「向下」工作?或者那被認爲是好的?

  3. 服務是否僅包含與從數據庫/存儲庫過濾和處理信息直接相關的功能,或者可以考慮純專用於加密和生成隨機字符串/密碼或類處理提供者依賴方功能的類服務呢?或者他們/也許會被視爲實用類?

  4. 是否有一種很好且可以接受的方式來操作服務中的會話,或者這應該傳遞給控制器​​並在那裏處理?

+2

嗨,歡迎來到stackoverflow。我意識到MVC是一個棘手的主題,但你的問題是廣泛的。如果你閱讀了常見問題解答(http://stackoverflow.com/faq#dontask)'如果你可以想象整本書可以回答你的問題,你就會問得太多了。「有很多關於mvc的書籍。我的建議是試着製作一個mvc框架,然後在彈出的時候詢問具體的問題。沒有人可以給你的答案,這將有助於MVC纔有意義。這種理解來自經驗。 – Dave 2012-07-28 00:47:03

+1

你是在談論ASP.NET MVC還是MVC模式?你的標籤會讓人感到困惑,因爲它們不是一回事。 – 2012-07-28 01:20:21

+0

嗨和感謝您的歡迎;)我談論的是asp.net MVC,我之所以用非常廣泛的話來說是因爲我在尋找更多的通用指南(如果可能的話),然後精確地回答一個特定的問題。 Luxspes似乎迴應了我正在尋找答案的水平,所以我很高興與這個答案,如果現在有一個有用的補充。在旁註中,我看到有人推薦「Clean Code」這本書,所以我想檢查一下,看看它是否有助於我進一步深入該主題。 – Baserz 2012-07-28 08:28:32

回答

1

服務不應該依賴於表現層,所以 通過這樣的東西的HttpContext到服務/服務功能 通過contstructor和類似的是一種不好的做法,正確

如果您可以避免它,避免它。但這取決於,如果它是表示層的服務,那麼它可以是好的。

應該沒有引用對方的服務?他們是否只有 「向下」工作,如存儲庫依賴性?或者說是 認爲可以嗎?

如果你能避免它,避免它。它dependes你的架構,如果,例如,你在asp.net的MVC的工作,你會在避免這種,並保持這在Controller級別編排您的多個服務的那種代碼做好

會服務僅包含直接涉及從數據庫/存儲庫過濾和處理信息的功能,或者可以考慮例如純專用於加密 並且生成隨機字符串/密碼或類處理提供商的類別 依賴方功能服務作爲服務好?或者他們/其中一個可能是 認爲工具類?

您可以使用服務來過濾和處理來自數據庫/存儲庫的信息,或者您也可以創建一個純粹專用於加密並生成隨機字符串/密碼的專用服務。服務類,讓他們跟着Single Responsability Principle

是否有操縱 服務中的會議一個很好的和接受的方法是很重要的或本應傳遞給控制器​​和處理呢?

這是因爲如果你的服務是無狀態的比例比較好,但如果你將不得不處理會話或其他生命週期的東西,你是在.NET開發Web系統,你可以做的最好的是使用asp.net mvc,與Unity集成,這樣你就可以得到Inversion Of Control,這樣你就可以使用會話處理life time managers