首先，我已经看到了很多有关此问题，但是背后的原因却不够多。如果我的问题不够好，应该删除，我会理解的。
例如，我看过这个问题，有超过45个赞成票的答案说他建议您将业务逻辑放入模型中，这听起来很合逻辑。
但是，我的第一个大型项目已经在控制器中完全使用了所有BL，因为我没有对这些事情提出疑问，而是看一下如何完成操作（AccountController如果您选择带有表单身份验证的MVC，该操作会自动添加）。所有方法看起来都充满了BL。还是可能添加的最少代码量让我无所适从？
youtube上的一个人通过将所有逻辑放到模型中来问我他是否正确，起初我不是！然后我开始认为也许他是对的！？
那么，毕竟我应该把业务逻辑放在哪里？如果在模型类中，那么在控制器中的方法中应该考虑多少代码是正常数量？一行最多只能在控制器中的模型中调用某种方法，然后返回到视图？
Answers:
由于两个原因，我倾向于将域逻辑放入模型中。
该模型中应该没有UI代码，因此更易于测试。只要有可能，我都希望在编写任何UI代码之前拥有一个可以正常工作（意味着完整的测试覆盖范围）的模型。控制器可以相信模型在做正确的事情，并且只处理UI问题。
如果将域逻辑放在控制器中，则在不同应用之间甚至不同控制器之间共享并不容易。
#2因为我发现自己很难在控制器之间共享（不得不使用静态方法）！
我喜欢保持模型整洁，即仅具有属性而没有业务逻辑。我一直认为将依赖项注入到控制器中是很好的，这些依赖项包含了我在模型上执行的逻辑。我喜欢在可能的情况下坚持单一责任原则，并且发现使用大量方法的模型会很快膨胀。两者都有优点和缺点，注入很多依赖项会产生开销，但允许隔离测试并保持类简单，最终您将拥有精简的控制器。尽管我的逻辑实际上不是作为班级成员存在于模型中的，但它仍然是业务逻辑。我倾向于在控制器中没有定义业务逻辑，因为像Httpcontext这样的嘲笑之类的东西有些噩梦，而且是不必要的。
该业务逻辑属于问题域，一切都属于问题域进入到模型中MVC。
该控制器应负责从模型传递数据到视图和从视图回到模型。因此，控制器是用户与之交互以及程序如何建模和存储问题状态之间的桥梁。该管道，可以这么说。
这里的关键是业务逻辑和管道逻辑之间的区别。在我看来，自动生成的帐户控制器的工作主要是管道，而不是真正的业务逻辑。请记住，管道逻辑不一定完全短，因此您无需施加人为的限制（例如“控制器中最多X个呼叫数”）。
我的团队从webforms（asp.net）转到mvc时，进行了大量研究，并提出了以下结构。据我说，它与应用程序的大小无关。关于保持代码干净清晰。
DAL项目
AccountsDAL.cs --- > Calls SP or any ORM if ur using any
BLL项目
AccountsBLL.cs ---> Calls DAL
网络项目
Model
AccountsModel --- > Contains properties And call BLL
Controllers
IndexController ---> Calls Models and returns View
Views
Index
控制器应负责模型和视图之间的数据传递。除此之外，不应有任何不必要的代码。例如，如果要记录日志，则应在模型级别而不是控制器上完成。
关于这个话题似乎有些困惑。大多数情况下，人们似乎倾向于将MVC模式与N层架构相混淆。现实情况是两种方法可以一起使用，但是一种方法不依赖于另一种方法，并且都不是必需的。
N层体系结构与将应用程序分成多个层有关。一个简单的示例是将应用程序划分为表示层，业务逻辑层和数据访问层。
MVC是一种处理应用程序表示层的设计模式。完全有可能按照MVC方法设计应用程序，而无需将业务逻辑和数据访问逻辑与表示层分开，从而最终得到单层设计。
结果，如果您遵循MVC方法而不将应用程序划分为多个层，则最终将导致模型，视图和控制器将业务规则和数据访问逻辑与其他逻辑混合在一起。
根据定义，在N层体系结构中，表示层仅应能够与业务逻辑层进行通信，因此应确保任何MVC组件只能与业务逻辑层进行通信。
如果您要构建的应用程序不涉及表示，因此不涉及表示层，则不必担心MVC模式。但是，即使不涉及表示层，您也可能仍然可以将应用程序划分为多个层，从而遵循N层设计。
一般来说，业务逻辑不应驻留在任何MVC播放器中；它只能由您的控制器操作消耗。
正如许多人提到的，最好创建一个库来托管业务逻辑，作为一组与客户无关的可重用组件。
通过这种方式，我们可以大大提高软件的可重用性，兼容性，可伸缩性和可测试性。我们还减少了对某些框架功能的依赖，这使向新/不同技术的移植变得更加容易。
多年来，将我们的业务逻辑抽象为一个独立的程序集（一个或多个程序集）一直对我们有好处。然后，几乎任何.NET技术（ASP.NET MVC / API / Core，WPF，Win Forms，WCF，UWP，WF，控制台等）都可以使用我们的业务逻辑。
此外，我们希望中间层能够处理业务规则和验证逻辑，以减少对.NET MVC框架的依赖。例如，我们避免使用.NET MVC验证帮助程序，而是依靠我们自己的帮助程序。这是另一个因素，使我们可以轻松使用任何.NET技术的业务逻辑。
通过这种方式在逻辑上设计我们的中间层，使我们能够轻松实现以下物理体系结构：
它是用Peasy.NET编写的，多年来为我们提供了很好的服务。事实上，我们决定将其开源。
如果有人对我们的中间层是什么样子感到好奇，那么这里有一个与客户无关的业务层示例。它还展示了多个.NET客户端（ASP.NET MVC，Web Api和WPF）的使用情况。
希望这对某人有帮助！
业务逻辑不应进入模型视图或控制器。应该有一个单独的业务逻辑层；该层的唯一目的是处理您的业务逻辑。这与SOLID更加一致。
如果将业务逻辑放在MV或C中，则最终会导致难以测试/重用的代码。
将逻辑放入模型怎么样？
那是一个不好的解决方案。
您将最终陷入依赖地狱，其中对象依赖对象。
即使您拥有简单的简单函数，您仍然必须满足所有依赖关系才能调用它。
这也将导致不必要的和未使用的数据传递周围没有任何理由。这也可能会影响性能，具体取决于性能的恶化程度。
我还应该提到，单元测试在a **中变得很痛苦，因为您必须模拟多个对象才能测试一个简单的函数。
适用清洁守则的原则
控制器
在您的控制器中，您应该能够使用依赖注入来注入业务逻辑层。确保您的控制器仅用于将信息路由到业务逻辑层。控制器不应直接在其中包含业务逻辑。任何验证都需要IValidatable在模型上进行。任何业务逻辑都需要路由到单独的层。
Payment和Product作为实例变量的新模型？你给那个物体起什么名字？如果视图中未使用模型，则不再是模型。它是单独层的一部分。理想情况下，您上的那堂课应该只从“付款”和“产品”中获取所需的信息，以完成工作。如果只需要productNameand和price，则应该只接受这两个参数，而不是整个对象。
我知道这是关于MVC的问题，但我认为我要举的示例（Web API）将很有用。
我正在开发我的第一个Web API，并且正在重用其他应用程序中的业务逻辑。具体来说，它来自外部DLL，因此我的API仅用于与SAP解决方案“对话”，接收来自PO的请求并将响应发送回去。
我如何将我的逻辑（已实现）放入控制器？我不需要 我的控制器将仅接收，验证请求并撰写响应以将数据发送回去。
我正在使用ViewModel类，它们必须具有的是一个映射函数，仅用于从TransferObjects中读取信息（来自外部DLL）并转换为ViewModel。
我对拥有业务逻辑的应用程序（在本例中为Web API）不满意，我认为可重用性将因此丢失。
我将业务逻辑视为我注入控制器的依赖项。
我在旧版中做了很多重构，以提供可单元测试的解决方案，我不得不创建许多接口，并在旧版中实现一些设计模式才能提供此解决方案。
在我看来，业务层必须位于应用程序之外，最好在另一个类库中。因此，您将在您的应用程序中实现一个真正的分离概念。
当然，如果您的CORE（业务）是您的应用程序（API / WebSite），则业务规则将实现到您的MVC类中。但是在将来，如果您要开发一个新的应用程序并且某些业务规则是相同的，那么我敢打赌，仅维护两个应用程序中实现的相同逻辑将有很多问题。