幾天前，Derik Whitaker發表了一篇文章，達到了我一直以來很好奇的一點：控制器中是否應該存在業務邏輯？到目前為止，我見過的所有ASP.NET MVC演示都將存儲庫訪問和業務邏輯放入了控制器中。有些人甚至還在那里進行驗證。這導致相當大的，腫的控制器。這真的是使用MVC框架的方式嗎？看來這最終將導致許多重復的代碼和邏輯散布在不同的控制器上。
3 回答
白豬掌柜的
TA貢獻1893條經驗 獲得超10個贊
業務邏輯實際上應該在模型中。您應該針對胖模型，瘦控制器。
例如，與其具有：
public interface IOrderService{
int CalculateTotal(Order order);
}
我寧愿擁有：
public class Order{
int CalculateTotal(ITaxService service){...}
}
這假設稅收是由外部服務計算的，并且需要您的模型知道與外部服務的接口。
這將使您的控制器看起來像：
public class OrdersController{
public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}
public void Show(int id){
ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
}
}
或類似的東西。
湖上湖
TA貢獻2003條經驗 獲得超2個贊
您可以查看Stephen Walther撰寫的這篇很棒的教程，其中顯示了“使用服務層進行驗證”。
了解如何將驗證邏輯從控制器操作中移出并移到單獨的服務層中。在本教程中，Stephen Walther解釋了如何通過將服務層與控制器層隔離來保持關注點的清晰分離。
LEATH
TA貢獻1936條經驗 獲得超7個贊
控制器中不應包含業務邏輯?？刂破鲬摫M可能的瘦，最好遵循模式：
查找域實體
對領域實體采取行動
準備數據以查看/返回結果
另外，控制器可以包含一些應用程序邏輯。
那么我該把業務邏輯放在哪里？在模型中。
什么是型號？現在，這是一個好問題。請參閱Microsoft模式和實踐文章（對AlejandroR的出色發現表示贊賞）。這里有三類模型：
視圖模型：這只是一個數據包，具有最少的（如果有的話）邏輯來往于視圖之間傳遞數據，其中包含基本的字段驗證。
域模型：具有業務邏輯的胖模型，對單個或多個數據實體（即，給定狀態下的實體A而不是對實體B的操作）進行操作
數據模型：感知存儲的模型，單個實體中包含的邏輯僅與該實體相關（即，如果字段a則字段b）
當然，MVC是一個范式，有多種形式。我在這里描述的只是MVC占據頂層，請參閱Wikipedia上的本文。
如今，MVC和類似的模型視圖演示者（MVP）是“關注分離”設計模式，這些設計模式僅適用于較大系統的表示層。在簡單的場景中，MVC可以代表系統的主要設計，直接進入數據庫。但是，在大多數情況下，MVC中的Controller和Model對Service或Data層/層具有寬松的依賴關系。這一切都與客戶端-服務器架構有關
- 3 回答
- 0 關注
- 1369 瀏覽
添加回答
舉報
0/150
提交
取消