Asp.Net MVC服務層 - 附加服務vs通過參數

我正在旋轉一個MVC5應用程序在遺留的webforms站點內，以幫助重構/替換一些非常舊的代碼。一路上，我發現，正如舊webforms的典型情況，有一個巨大的類被創建來管理會話SessionManager中的值。顯然，這不是很可測，所以我已經隱藏的屬性，我需要一個服務背後：Asp.Net MVC服務層 - 附加服務vs通過參數

public class LegacySessionService : ISessionService 
{ 
     public IUser GetCurrentUser() 
     { 
      return SessionManager.CurrentIUser; 
     } 
}

現在的問題是，其他服務中，是清潔讓控制器訪問會話服務並通過IUser，或讓工作服務知道並訪問會話服務？

public class MyController : Controller 
{ 
    /*skipping obvious dependency injection*/ 

    public ActionResult DoStuff() 
    { 
     var viewModel = _someotherService.DoStuffWithIUser(_sessionService.GetCurrentUser()) 
     return View("DoStuff", viewModel) 
    } 
}

public class SomeOtherService 
{ 
    /*skipping obvious dependency injection*/ 

    public ViewModelClass DoStuffWithIUser() 
    { 
    var currentUser = _sessionService.GetUser(); 
    //do more stuff, return ViewModel 
    } 
}

哪個更正確的建築，爲什麼？我不知道。

來源

2014-11-21 Eric H

第二種選擇是兩者中較好的一種，在單一責任原則下，控制器應該關注協調模型和視圖層，而不是模型層如何檢索當前用戶等信息。

雖然你的第二個例子仍然可以改進。您的SomeOtherService有一個假設，即應從SessionService中檢索當前用戶。如果您改爲從HttpContext或將來的其他地方閱讀用戶，該怎麼辦？我建議創建一個ICurrentUser接口並將其添加到SomeOtherService的構造函數中。然後你可以創建一個具體的實現，稱爲CurrentUserFromSession，它從SessionService中讀取並注入。如果您更改了當前用戶的檢索方式，則可以創建ICurrentUser的新實現，更改DI容器，而不必重新打開SomeOtherService。

來源

2014-11-21 20:20:34

Asp.Net MVC服務層 - 附加服務vs通過參數

回答

相關問題