我应该从另一个AppService中调用AppService吗？

Question

背景

目前我正在使用一个文档和记录管理系统（DRMS）。由于一些技术限制，我需要存储一个“视图”文件和一个“源”文件（DOCX或XLSX）。视图文件是用户日常使用时打印、下载和查看的PDF文件，而源文件则是可编辑的文件。当用户需要更新文件时，他们将下载源文件进行更新，并上传新的视图文件和相应的源文件。

目前我无法实现XLSX查看器/编辑器，并且由于文件数量的原因，我无法迁移到ODFs以使用可用的开源查看器。

现在我有两个模型如下：

public class Document {
    //Other fields
    public virtual List<DigitalFile> Files { get; set; }
}

public class DigitalFile {
    //Other fields
    public virtual Document FileOf { get; set; }
}

Document模型包含所有“业务”数据，而DigitalFile模型包含有关文件本身的数据（路径、URL、类型等）。

每次创建文档时，它将具有1个查看文件（必需），并且可能具有1个源文件（某些文档可能无法编辑）。从这里可以知道，当创建/更新文档时，至少还会创建/更新1个数字文件。

问题/疑问

我将拥有一个DocumentAppService来处理所有CRUD操作，但这里是我的疑惑所在，我是否应该从另一个AppService中调用AppService？我的意思是，当创建文档时，Create方法是否应该调用DigitalFileAppService中的另一个Create方法？还是说如果DocumentAppService自行处理所有内容会更好？

现在，DigitalFile上的所有CRUD操作都与Document上的操作相关联，这就是我对实现文件的AppService感到疑惑的原因。

- IvanGrasp

Answer 1

我不建议在同一域中的另一个服务中调用应用程序服务。应用程序服务是设计用于从UI层调用的。它实现审计日志记录、授权、验证等功能...如果您在同一应用程序层中使用代码，则可能不需要这些功能。

应用程序服务方法是您的应用程序的公共端点。从另一个应用程序服务调用应用程序服务就像从应用程序外部进入并从不同的点进入。如果另一个应用程序服务方法的签名发生更改（由于UI中的要求更改），您也可能不想更改应用程序服务方法。

我的建议是将共享代码分离到另一个类中（可能是域服务），并从两个应用程序服务中使用。

- hikalkan

---

我在看到这个之前就开始写我的答案了，很高兴我有类似的理解 :) - aaron

我以为我已经阅读了所有关于ABP的文档。在深夜尝试解决问题后，阅读答案后，我再次去“文档”查找域服务。看着例子，那正是我需要的。我仍然不知道是否应该为DigitalFile拥有一个应用程序服务，因为它们不会与文档分开创建，但我有东西可以先行处理。谢谢。 - IvanGrasp

Answer 2

理想情况下，一个 AppService 不应该调用另一个 AppService。

一个应用程序服务应该将数据传输对象（DTO）映射到领域对象（实体），应用程序逻辑，并将这些对象传递给相应的领域管理器进行持久化。

注入多个管理器是完全可以的，特别是如果映射配置正确的情况下。在可能的情况下，应用程序服务不应依赖于另一个应用程序服务。

---

现实情况下，一个应用程序服务可能通过接受嵌套的“次要” DTO 提供方便（以及由于减少服务器调用而提高速度）。这些 DTO 可能涉及单独的应用程序逻辑。

一种清洁的方法是在依赖的应用程序服务中创建内部方法，例如 Create 方法的 CreateInternal。内部方法不会转换为动态 Web API 方法，并且避免了拦截器的授权和验证开销。

此外，ABP 框架提供了 RemoteService(IsEnabled=false) 属性，如果您想直接从 MVC 控制器调用这些方法，则需要将这些方法设置为公共方法。

- aaron

---

感谢您的输入，虽然我已经接受了hikalkan的答案，但在开发过程中我会考虑这些信息。 - IvanGrasp

没问题 :) - aaron

Answer 3

AppServices与您的实体无关。 AppServices可以是一个功能需求，因此可以有一个UploadAppServices，在那里将创建两个实体。

- novac

Answer 4

你可以创建一个通用类，只需要将dbContext作为参数传入，并编写你想要在许多服务之间共享的函数。

- fatma zayed