UI VS業務邏輯MVC

Question

所以MVC被分成

• 型號
• 查看
• 控制器層

我想我有準備以後有什麼每層做一抓許多頁面，但我仍然難倒一個區域，這是如果事情應該在模型或控制器去。

據我所知，數據存儲類應在控制器 去，我明白，用戶界面改性劑（即右拉模型），應在控制器

但是，我們的模型修改器去。舉例來說，如果我們採用軟件購物車的方式，可以說有人點擊結賬按鈕，填寫他們的付款細節和全部批准，回發恰巧處理這一點。

回發對象需要

1. 添加到數據庫表中的條目說讓X用戶下載Ÿ軟件
2. 發送回執給用戶
3. 登錄購買

通常（在一個非MVC）的方法，我會創建一個類來處理軟件表的訪問生成，它將調用EF來存儲信息。我會有一個二級班來發送通知，第三班學習記錄信息。

我還應該在MVC中有這些類嗎？如果是的話，他們會作爲控制器還是模型？

Answer 1

以上定義的所有三點構成了應用程序模型的一部分;控制器應該只處理模型和呈現給用戶的UI表示（視圖）之間的編排。

秉承SOLID原則，絕對會同意，我們面對的是（至少）三個獨立的組件：

1. 仍然存有用戶X下載軟件y中的數據
2. 發出收據
3. 記錄

有很多方法可以組織架構和組件來完成此操作。一種方法是獲得依賴於這三個組件的應用程序特定組件/服務並使用它們來執行列出的操作。然後控制器只依賴於這個組件。

Answer 2

要在更多的細節上Russ' great answer擴大，這樣考慮：

public class CheckoutController 
{ 
    private readonly ICommandHandler<CheckoutCommand> _checkoutHandler; 

    public CheckoutController(ICommandHandler<CheckoutCommand> checkoutHandler) 
    { 
     _checkoutHandler = checkoutHandler; 
    } 

    [HttpPost] 
    public virtual ActionResult Post(CheckoutViewModel viewModel) 
    { 
     if (!ModelState.IsValid) return View(viewModel); 
     var command = Mapper.Map<CheckoutCommand>(viewModel); 
     _checkoutHandler.Handle(command); 
     return RedirectToAction("Complete"); 
    } 

    public virtual ActionResult Complete() 
    { 
     return View(); 
    } 
} 

控制器沒有做任何事情businessy可言。它爲用戶提供控制流程。現在，考慮你有這樣的相關性注入到控制器：

public class DomainCheckoutCommandHandler : ICommandHandler<CheckoutCommand> 
{ 
    private readonly IEntityDataStorage _repos; 
    private readonly IEmailSender _email; 
    private readonly ILogger _log; 

    public DomainCheckoutCommandHandler(IEntityDataStorage repos, 
     IEmailSender email, ILogger log) 
    { 
     _repos = repos; 
     _email = email; 
     _log = log; 
    } 

    public void Handle(CheckoutCommand command) 
    { 
     // use _repos to Add an entry to a database table 
     // use _email to issue the receipt 
     // use _log to log the purchase 
    } 
} 

有關於使用thesethreeposts接口+ DI這樣一些偉大的信息。

最好的部分是您可以將MVC項目之外的所有其他代碼 - 接口，域類和其他接口實現 - 全部移出。這樣，MVC項目中沒有任何事情做任何事情。它只是委託給由業務層或其他類庫實現的接口。