我问过几位开发人员，每次都得到了不同的答案。
假设我在MVC框架中工作，我有一个名为validator的类。假设这个对象有一组方法，可以用来告诉你电子邮件或电话号码是否有效，或者给定的值中是否真的有内容
假设我想将此服务作为我正在创建的模型的属性。我可以简单地将它注入到我的模型类的构造方法中。然而，这个服务在MVC中的位置是什么？它是一个模型吗？
文件应该存储在哪里？和模特们在一起？在它自己的目录中，也许叫做services？
我认为我对mvc中的Model有不同的看法[遗憾的是，没有双关语]，但服务肯定应该进入Model层。
首先，模型不应该是类。该模型是的模型，属于一个应用程序。应用程序在不同的方面（包含在模型层中）被建模：实体、映射器、服务。
例如，这可能是一个代表这个概念的文件层次结构：
应用控制器模型实体映射器服务看法
假设我想将此服务作为我正在创建的模型的属性。我可以简单地将它注入到我的模型类的构造方法中。然而，这个服务在MVC中的位置是什么？它是一个模型吗？
我假设"模型"确实是一个Entity，一个表示域概念的对象。在这种情况下，服务不应该是实体的属性。服务应该由控制器使用，以执行它们被调用执行的任何操作，然后映射器将根据服务执行的结果构建实体。
我目前的理解很大程度上来自于这个答案，你绝对应该阅读它以进一步理解。
这取决于服务的职责。您的应用程序中可以有不同类型的服务。例如
- 一个处理用户输入并返回实例化模型类的服务，该类将输出要由视图呈现的内容（可能位于控制器层）
- 一种在银行应用程序中的账户之间转账的服务（应该位于模型层）等
假设我在MVC框架中工作，我有一个名为validator的类。假设这个对象有一组方法，可以用来告诉你电子邮件或电话号码是否有效，或者给定的值中是否真的有内容
第一件事。你不想要这些超级强大的类，因为它们很难维护。他们违反了单一责任原则（参见https://en.wikipedia.org/wiki/Single_responsibility_principle)。
验证器在您的应用程序中可能有不同的职责。
- 它们可以帮助用户判断"给定的值是否真的包含内容"。这些可以进入控制器层
- 他们还可以执行商业规则，比如说"电话号码是否有效"。这些应该在模型层中
假设我想让这个服务成为我正在创建的模型的属性。。。我可以简单地将它注入到我的模型类的构造方法中。
最好先进行验证，然后注入真正的类依赖项，如电话号码和电子邮件。OOP是关于抽象现实生活中的概念：一个人有一个有效的电话号码和一封有效的电子邮件，而不是一个验证器。
文件应该存储在哪里？和模特们在一起？在它自己的目录中，也许叫做服务？
服务应该在它们自己的命名空间中创建，如"ProjectName''Model''Service"answers"ProjectName''Controller''Service"。
此外，还有很多文章和线程涉及MVC在构建整个应用程序方面的失败（比如https://softwareengineering.stackexchange.com/questions/207620/what-are-the-downfalls-of-mvc)值得一读。
它显然是模型层的一部分，因为它包含业务逻辑。我的验证器存储在/models/validators中。并且可以在Forms/API/等内部使用。。。