我对什么是业务逻辑感到困惑。我假设它是用 Controller 编写的，但后来我在互联网上搜索它，但我发现很多人说它是指模型。我很困惑。一些社区成员给我的建议是我的问题是一样的，但你做错了。我对这些问题的答案感到困惑。有人说模型是业务逻辑，但我认为 Controller 是业务逻辑。所以请理解我的疑问。
【问题讨论】：
控制器将更干净且更具可读性，然后您的所有控制器功能将是纯动作。
您可以在模型（服务）中尽可能多地分解业务逻辑。代码可重用性更好，对模型和存储库没有影响。
业务逻辑可能用在一个或多个地方，因此模型是编写代码的好地方。
我们举个例子：
第一个控制器：
var getBusinessLogic = utilService.getBusinessLogic();
第二控制器
var getBusinessLogic = utilService.getBusinessLogic();
模块（服务）
this.getBusinessLogic = function () {
// return businessLogic
}
【讨论】：
在一般意义上，业务逻辑与应用程序中由应用程序所有者确定的逻辑相关。
在许多不同的应用程序中发现的对于应用程序的功能来说必不可少的通用逻辑不被视为业务逻辑。这可能包括例如实体的创建-读取-更新-删除、网络调用、身份验证等
业务逻辑是特定应用程序所有者独有的逻辑。
因此，业务逻辑可以出现在应用程序代码的任何部分。
但是，有些人会主张，例如“薄控制器”和“厚模型”。瘦控制器是一种几乎不包含业务逻辑的控制器，并且严重依赖于模型来执行适当的业务逻辑，例如在创建、读取、更新或删除操作期间。
在角度上是类似的，角度控制器主要负责为范围准备模型数据，就像 API 控制器负责为 API 请求准备数据一样，您可以旨在最小化控制器中的业务逻辑.
但是，业务逻辑也并不总是非常适合模型 - 如果更新一个模型需要更新其他模型怎么办？这就是为什么模型控制器框架经常会提供另一种选择——服务。服务提供了一个更抽象的地方来执行业务逻辑，例如与单个模型无关。
总体而言，一个不错的选择是尝试保持控制器“精简”并将业务逻辑保留在模型和/或服务中。
【讨论】：