我正在尝试使用ASP.Net学习MVC，并阅读Steve Sanderson的书。有一件事让我感到困惑，那就是业务逻辑应该放在哪里？
例如，当删除一个产品时，Sanderson只在他的CartController中调用了productsRepository的Delete方法。这对我来说很奇怪，因为如果有任何业务逻辑，比如确保该产品首先不在任何人的购物车中等，它必须放在products repository或CartController中。
这两个地方都不适合放置业务逻辑；products repository旨在轻松替换（从使用db切换到使用session），而使用Controller意味着您将业务逻辑放在UI层中。
难道他不应该使用一个包含业务逻辑并调用repository的delete方法的类吗？repository是业务逻辑类的成员变量吗？
public virtual ActionResult ProductCart()
{
var applicationService = <obtain or create appropriate service instance>
var userID = <obtain user ID or similar from session state>
var viewModel = applicationService.GetProductCartModel( userID );
return View( "Cart", viewModel );
}
public virtual ActionResult AddProductToCart( int productID )
{
var domainService = <obtain or create appropriate service instance>
var userID = <obtain user ID or similar from session state>
var response = domainService.AddProductToCart( userID, productID );
return Json( new { Success = response.Success, Message = response.Message } );
}
现实情况是，这个问题没有银弹，而且它实际上是一个情境相关的问题。我喜欢尽可能地分开事物，业务逻辑其实只是应用程序中的另一层。
我设计了一个受BDD启发的决策引擎，并将其作为一个开源项目发布在NuGet上。该项目名为NDecision，你可以在NDecision项目主页上阅读相关信息。
NDecision使得决策树业务逻辑的实现变得非常简单，如果你喜欢Gherkin语法和流畅编程实践，使用它会让你感到非常舒适。下面的代码快照来自项目网站，展示了业务逻辑的实现方式。
这可能对您来说不是一种解决方案，但是想法是，如果您已经在一个程序集中拥有了您的域模型 - 这是另一个回答中建议的一个很好的想法和常见做法，那么您完全可以有另一个程序集来处理您的“决策树”。NDecision 正是出于此目的而编写的，将逻辑分离成一个独立层。
希望这会对您有所帮助。