2016-10-23 40 views
0

我正在開發ASP.NET Core應用程序。爲了保持控制器精簡,大部分數據操作都是在ViewModels中完成的。一切工作正常 - 這兩個問題,然而,來自ViewModel的訪問控制器數據

  1. 的ViewModels沒有獲得ControllerContext信息(或者我無法弄清楚如何得到它)。例如,Session,User和其他控制器可以免費獲得的內容。

  2. ViewModels不接受依賴注入(再次,或者我不知道如何傳遞它)。例如,如果我有構造函數MyController(ApplicationDbContext db),我得到db沒有任何問題。但是,如果我有ComplexViewModel(ApplicationDbContext db)我得到null傳遞。顯然,我有完全一樣的services.AddDbContext<ApplicationDbContext>()在啓動

現在我路過無論是從控制器需要明確的視圖模型。但感覺應該有更好的辦法。

+3

我建議您的ViewModels不包含任何行爲,並且將所有行爲都移至自定義服務。這應該可以解決你的問題。 –

回答

1

查看模型應該是簡單的POCO在視圖和動作方法之間傳輸數據。我認爲將所有業務邏輯(甚至數據訪問)混合到查看模型是一個糟糕的主意。你可以考慮在服務中這樣做。您可以將這些服務注入您的控制器。

例如。

呦獲得用戶的信息,您可以考慮創建一個服務

public interface IUserService 
{ 
    UserDto GetUser(int id); 
} 
public class UserService : IUserService 
{ 
    IUserDataAccess userDataAccess; 
    public UserService(IUserDataAccess userDataAccess) 
    { 
    this.userDataAccess=userDataAccess; 
    } 
    public UserDto GetUser(int id) 
    { 
    // with this.userDataAccess, get a User and map to UserDto 
    // to do : return something 
    } 
} 

所以,你的控制器將保持精簡

public class UserController : Controller 
{ 
    private readonly IUserService userService; 
    public UserController(IUserService userService) 
    { 
    this.userService = userService; 
    } 
    public ActionResult Details(int id) 
    { 
    var userDto= this.userService.GetUser(id); 
    return View(userDto); 
    } 
} 

現在你可以有一個UserDataAccess其查詢數據,並注入,爲類UserService

使用這種方法,您的視圖模型不知道您使用的是什麼數據訪問技術。想象一下,明天你決定爲了性能原因放棄EF,並希望切換到Dapper,你只需創建一個名爲「DapperUserDataAccess」的IUserDataAccess的新實現,並使用該配置註冊即可。沒有其他代碼更改:)

+0

概念上,我同意。但是,正如任何業務線應用程序一樣,有很多業務邏輯和數據訪問。創建一個服務看起來像不必要的重複。爲了構建您的示例,示例ViewModel將是'CustomerCreditViewModel',它可以獲取有關客戶的數據,訂單歷史記錄,還需要有關用戶審批限制的信息(該示例已完全組成)。 ViewModel *似乎是做這一切的好地方,迄今爲止效果很好。但可能是時候重新考慮這種方法了。 – Felix

+0

我完全不同意。恕我直言,我認爲你不應該混合你的視圖模型與數據/業務邏輯。他們應該是精簡的POCO。它不應該有任何關於您的數據訪問的知識。再次,這是我個人的意見,我沒有任何權利強加給你的。你可以自由地關注你認爲正確的事情。 – Shyju

+1

heh - 我*不認爲我不同意你的看法)我剛纔說的,最初將商業邏輯放入虛擬機*看起來像一個好主意(至少比先前居住的控制器更好) - 但現在是時候轉向服務了。 – Felix

相關問題