在Ionic中,我提供了两项服务来提供数据
export class DocumentService {
constructor(favorisService: FavorisService) { }
async GetById(id: number): Promise<DocumentModel>{
let path = this.favorisService.getPath();
// Get document's additionnal datas from BDD
// Gets back document depending on path
}
async GetById(id: number): Promise<DocumentModel>{
//request server and sends back a document
}
}
export class FavorisService {
constructor(httpServer: httpServerService) { }
async Synchronize(id: number): Promise<FavorisModel>{
//if favoris was never synchronized, get document on server
//then downloads document with document.getDocument
}
GetPathToDocument(){//returns favoris's document's path}
}
我不明白为什么不能在documentService和documentService中导入favorisService,而在favisisService中却无法导入favorisService,服务的目的是提供数据,为什么它们不能互相提供数据?
我做了第三个服务,叫做FavorisDocumentService
export class FavorisDocumentService{
constructor(
httpServer: httpServerService, favorisService: FavorisService,
documentService: DocumentService
) { }
async GetById(id: number): Promise<FavorisModel>{
this.favoris = await this.favorisService.getById(id);
this.favoris.document = await this.documentService.getById(id);
}
}
问题不是它不起作用(实际上是起作用),问题是我必须为每个组合或对象提供另一个服务。我之所以这样做,是因为我的项目较小,并且只有两个关系迫使我创建第三个服务,但是现在我必须制作“ DocumentFavorisUserServices”和其他文件(用我的示例,你可以说我只是将documentService放在avourisService,但有时我需要documentService中的favorisService)
不允许进行“循环依赖”的目的是什么,正确的方法是什么? (我与Ionic 4合作)
编辑----
收藏夹可以包含文档,但是文档并不总是与收藏夹链接,并且取决于收藏夹,此文档可以存放在不同的位置,具体取决于收藏夹的管理方式。因此,“路径”数据位于收藏夹内部,而不在文档中。这就是为什么有时需要在文档中添加偏好的原因,因为当我拥有“ getdocument”(放置在documentservice中)时,我需要该文档的路径(以将其取回)。这种情况下的单一责任原则是一种模糊,即哪个对象承担哪个责任(我对对象示例进行了编辑)
答案 0 :(得分:0)
我认为您的做法不正确。 FavorisService
应该只获得“收藏夹”,而DocumentService
应该只忙于处理文档。这些对象之间具有彼此的键,不应更改此键。如果您在组件中都需要这两个数据,则应该从这两个服务中查询。如果您倾向于大量使用此模式,则可以使用包装器服务(就像您一样)
尝试让您的服务仅承担一项责任和/或重组没有循环引用的数据对象结构。
在Ionic中不允许循环依赖的原因是,在ES5中不允许这样做。
您在代码中进行的引用越多,测试就越困难,并且理解起来也越复杂-您最终会得到意大利面条式代码。此外,许多引用会创建循环依赖关系,从而直接导致错误。
在ES6中,这已得到一定程度的解决,但是我相信您永远都不应具有循环依赖项(请参见上面的引用)。