Question

上下文

目前我正在使用文档和记录管理系统（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模型包含有关文件本身的数据（路径，网址，类型等）

每次创建文档时，它将具有1个视图文件（必需），并且可能具有1个源文件（某些文档可能无法编辑）。由此您可以知道，在创建/更新文档时，至少会创建/更新1个数字文件。

问题/疑问

我将有一个DocumentAppService来处理所有CRUD操作但是我怀疑的地方是，我应该从另一个AppService调用AppService吗？我的意思是，在创建Document时，Create方法是否应该在DigitalFileAppService中调用另一个Create方法？或者如果DocumentAppService自己处理所有事情会更好吗？

现在，DigitalFile上的所有CRUD操作都与Document上的操作相关联，这就是为什么我对为文件实现AppService存有疑问。

Answer 1

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

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

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

Answer 2

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

应用程序服务应将数据传输对象（DTO）映射到域对象（实体），应用应用程序逻辑并将这些逻辑传递给相应的域管理器以实现持久性。

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

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

干净利落地执行此操作的一种方法是在依赖项应用程序服务中创建internal方法，例如： CreateInternal方法的Create。 internal方法未转换为动态Web API方法，并且避免拦截器的授权和验证开销。

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

Answer 3

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

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

3 个答案: