我对控制器的职责和对我的一段代码的服务有疑问。我有一个HTML表单来保存一篇文章，该文章可以随文本一起提交三个图像（缩略图，摘要和正文）。正文可以包含一些Base64格式的图像。我通过post Action获得它们，该Action接受DTO对象以支持所有输入。
我要执行的任务是：
我在这里有一个服务层，其中包含一些有关检查文章文本和图像逻辑的类。
我的问题是我应该如何在这里行动。哪些步骤适用于Controller，哪些适用于Service。
步骤2对我来说是最令人困惑的步骤。我应该在控制器中执行此操作，还是只将所有DTO传递给Service来分开它们本身？
或者关于检查文本，我应该检查例如控制器中的摘要文本长度还是应该由服务层检查？
有人可以向我解释这些吗？
答案 0 :(得分：1)
可能的duplicate。
控制器的职责是接受请求，调用处理并根据处理结果做出响应。 尝试查看SOLID原则，并始终尝试应用它们。
首先，DTO取决于您的体系结构设计，但是我想说DTO是一种抽象，它使您可以将域模型与客户端模型分离。 DTO应该被视为两层之间的数据表示，如果DTO跨越了不止一层，那么它可能不是DTO，而是业务或数据实体。
）从身体获取图像
这看起来像是您设计的能够接收所需数据的内容，但不是您的域模型关心的。 例如，如果您的表单允许您保存“销售广告”（由少量图像和一些文本组成），则可能是业务层（服务）中的这种数据聚合由一个或多个域对象表示，因此，您会收到任何形式的机构，更多地取决于技术或运输方式，并且对您的业务层应该透明。 考虑可重用性的一个很好的例子可以帮助您找到界限。例如，如果要从WCF服务中使用服务层，将如何重用它？ 您的服务应始终接收和公开域对象。 让用户组件负责解码/编码。
3）检查摘要和正文文本规则（以及所有其他检查）
似乎是一个验证，但我无法确定此验证是否仅与域有关。 控制器本身也会进行一些验证，以检查请求是否有效。 因此，如果在DTO结构上进行了此检查，则在尝试对其进行转换之前，可能是控制器验证，如果相反，则需要此验证来确定天气或是否可以保存输入，在这种情况下，很可能会被视为他人的责任。 您提到：
例如摘要文字长度
如果这是一条业务规则，那么我将其放置在验证对象中，该对象负责验证“摘要文本”，或者我们再次将其称为“销售广告”。
将域对象保存到数据存储中的责任通常委托给数据访问层，该数据访问层与数据库结构耦合并为业务层提供抽象。 这可以通过实施存储库模式来完成，也可以使用ORM来完成，我通常不添加逻辑以将数据持久化在业务层中。
另一个说明，这里您询问的是控制器责任，但要注意您的服务“层”，我经常看到代码中巨大的服务类封装了所有业务逻辑和验证，这很糟糕，因为再次违反了大多数坚实的原则。 看一下命令查询和装饰器模式，我喜欢它们，因为它确实可以帮助您将代码分解成较小的单个责任。 如有兴趣，请查看github（。net核心）上的示例项目。 我仍在处理文档，但应该足够清楚。