Model view controller 控制器或服务的责任？

我有一个关于控制器和服务的责任的问题，关于我的一段代码。我有一个HTML表单来保存一篇文章，它可以提交三个图像（缩略图、摘要和正文）和它们的文本。正文文本可以包含一些Base64格式的图像。我通过接受DTO对象以支持所有输入的post操作获得它们

我想做的任务是：

从客户端获取DTO

从身体获取图像

检查摘要和正文规则

检查获取的图像规则

检查缩略图、摘要和正文图像规则

拯救他们

我这里有一个服务层，它有一些关于检查文章文本和图像逻辑的类

我的问题是我应该如何在这里行动。哪些步骤适用于控制器，哪些步骤适用于服务

第二步对我来说是最令人困惑的一步。我是应该在控制器中完成，还是只是将所有的DTO传递给服务以将事物本身分离

或者关于检查文本，我应该检查控制器中的摘要文本长度，还是应该由服务层检查

谁能给我解释一下吗？

可能

控制器的职责是接受请求，调用处理，并根据处理结果作出响应。 试着审视这些原则，并始终尝试应用它们

首先，DTO，它取决于您的架构设计，但我要说的是，DTO是一种抽象，它允许您将域模型与客户机模型解耦。 DTO应被视为两层之间的数据表示，如果DTO跨越多个层，则它可能不是DTO，而是业务或数据实体

)从身体获取图像

这看起来像是您为能够接收所需数据而设计的，但不是您的域模型所关心的。 例如，如果您的表单允许您保存由少量图像和一些文本组成的“销售广告”，那么您的业务层（服务）中的数据聚合可能由一个或多个域对象表示，因此您收到的正文是否采用任何格式，更多地取决于技术或传输，并且应该对您的业务层透明。 一个很好的例子可以帮助你找到界限，那就是考虑可重用性。例如，如果从WCF服务使用服务层，您将如何重用它？ 您的服务应始终接收和公开域对象。 将解码/编码的责任留给消费者组件

3） 检查摘要和正文规则（以及所有其他检查）

似乎是一个验证，但我无法判断此验证是否仅与域相关。 控制器本身也会进行一些验证，以检查请求是否有效。 因此，如果在尝试转换DTO结构之前，对DTO结构执行此检查，可能这是控制器验证，如果需要此验证来确定是否可以保存输入，那么在这种情况下，很可能会将其视为其他人的责任。 你提到：

例如，摘要文本长度

如果这是一个业务规则，那么我将把它放在一个验证对象中，负责验证“摘要文本”，或者我们再次称之为“销售广告”

将域对象保存到数据存储的职责通常委托给数据访问层，该层与数据库结构耦合，并向业务层提供抽象。 这可以通过实现存储库模式或使用ORM来实现，我通常不会在业务层中添加逻辑来持久化数据

另一个注意事项是，这里您询问的是控制器的责任，但请注意您的服务“层”，我经常看到一个巨大的服务类封装了所有业务逻辑和验证的代码，这是非常糟糕的，因为这又违反了大多数坚实的原则。 看看命令查询和装饰器模式，我喜欢它们，因为它们确实可以帮助您将代码分解成更小的部分，只需承担一项责任。 如果您感兴趣，请查看（.netcore）上的这个示例项目。 我仍在编写文档，但应该足够清楚