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

问题描述：

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

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

现在我有两个模型是这样的：

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个源文件（某些文档可能不可编辑）。由此您可以知道，创建/更新文档时，至少还会创建/更新一个数字文件。

问题/疑问

我将有一个DocumentAppService来处理所有的CRUD操作，但这里就是我的疑问来了，我要打电话从其他AppService服务的AppService服务？我的意思是，当创建一个Document时，Create方法是否需要调用DigitalFileAppService中的另一个Create方法？还是应该更好，如果DocumentAppService自己处理一切？

现在，DigitalFile上的所有CRUD操作都与Document上的操作绑定，这就是为什么我不确定是否为文件实现AppService。

答

我不建议从同一个域中的其他服务调用应用程序服务。应用程序服务旨在从UI层调用。它实现了审计日志记录，授权和验证......并且如果您在同一个应用程序层中使用代码，它们可能不需要。

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

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

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

你的回答也很好，谢谢:) – hikalkan

我以为我已经阅读了所有关于ABP的文档。在深夜尝试解决问题时，在阅读答案后，我再次去“docs”寻找域服务。看看这些正是我需要的例子。我仍然不知道我是否应该有一个应用程序服务DigitalFile因为他们不会单独从文档中创建的，但我有一些在此期间的工作。感谢 – IvanGrasp

答

AppServices不需要与您的实体相关。 AppServices可以是一个功能需求，这样就可以有一个UploadAppServices，它将创建两个实体。

答

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

的应用服务应该映射数据传输对象（DTO的）域对象（实体），应用程序逻辑和传递这些到各自的域管理器（一个或多个），用于持久性。

注入多个管理器是非常合适的，尤其是在映射配置正确的情况下。在可能的情况下，应用程序服务不需要依赖于其他应用程序服务。

实际上，应用服务可以通过接受嵌套“次要”的DTO提供便利（和速度由于较少的服务器调用）。这些DTO可能涉及单独的应用程序逻辑。

干净地做到这一点的一种方法是在依赖项应用程序服务中创建internal方法，例如， CreateInternal为Create方法。该internal方法不会转换为动态Web API的方法和通过拦截授权和验证的避免开销。

此外，ABP框架提供了[RemoteService(IsEnabled = false)]属性，如果你想直接从MVC控制器调用这些方法 - 这样的方法需要公开。

感谢您的输入，虽然我接受hikalkan答案，我会在开发利用这个信息考虑在内。 – IvanGrasp

是的，没问题:) – aaron

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

相关推荐